This works around an issue with Matrix Authentication Service's `syn2mas` sub-command (at version v0.16.0),
which chokes with an error:
> Error: Failed to load Synapse configuration
> Caused by:
> invalid type: found unit, expected struct EnableableSection for key "default.cas_config" in homeserver.yaml YAML file
This issue is likely to be fixed in MAS v0.16.1 or v0.17.0.
This is a backward-incompatible change. By default, Ansible creates
users with (e.g.) `/bin/sh` on Linux, so changing to a no shell
leads to different behavior.
That said, it appears that using a shell-less user works OK with regard
to Ansible execution and starting the systemd services/containers later on.
* continuwuity support
* continuwuity support
* use main instead of commit tag
* fix docker image link
* migration from conduwuit
* fix yaml lint
* backup directories and linter fixes
* linter fixes
* Add matrix_bridges_msc4190_enabled flag for using msc4190 on supported mautrix bridges.
* Apply to_json to msc4190 in mautrix configs
* Add | to_json to mautrix bridge registration io.element.msc4190.
* require matrix_synapse_experimental_features_msc3202_device_masquerading_enabled for matrix_bridges_msc4190_enabled
* Also add msc4190 support for mautrix-telegram
The action will be used to lock issues and PRs to prevent necro-posting on closed ones which have not had any activity in the past year.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This also reverts e5574a405e because:
- it was causing issues on some servers (not clear why)
- such workarounds are no longer necessary when doing multi-stage building.
Various old guides mention this, but it seems like neither Element Web,
nor Element Desktop make use of it.
Element Web & Element Desktop use their own `config.json` configuration to figure out where
Element Call is.
Some Element Call setup resources say that `/.well-known/element/element.json` should be served on the base domain
and should contain content like this:
```json
{
"call": {
"widget_url": "https://call.element.example.com"
}
}
```
We were already generating the file via `matrix-static-files`, but weren't serving it yet.
This patch makes sure it's served on the `matrix.` domain, which allows
people to set up serving on the base domain via a redirect or reverse-proxying.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562
`group_vars/matrix_servers` was correctly populating `matrix_static_files_file_matrix_client_property_org_matrix_msc4143_rtc_foci_auto` with a list, but:
- the defaults for these variables were hinting that hashmaps are necessary
- merging of `_auto` and `_custom` was done as if for hashmaps, not lists
As a result, `/.well-known/matrix/client` looked like this:
```json
{
"org.matrix.msc4143.rtc_foci": {
"livekit_service_url": "https://matrix.example.com/livekit-jwt-service",
"type": "livekit"
}
}
```
.. instead of what's expected as per MSC4143 (https://github.com/matrix-org/matrix-spec-proposals/pull/4143):
```json
{
"org.matrix.msc4143.rtc_foci": [
{
"livekit_service_url": "https://matrix.example.com/livekit-jwt-service",
"type": "livekit"
}
]
}
```
Regardless of our incorrectly formatted `org.matrix.msc4143.rtc_foci`
configuration in `/.well-known/matrix/client`, Element Web still seemed
to be able to discover LiveKit JWT Service (and by extension, LiveKit Server) correctly,
even without this fix.
Apparently ensure-matrix-users-created is relevant only for components registered to "matrix_user_creator_users_auto" on group_vars/matrix_servers.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This change intends to explain how ensure-matrix-users-created and ensure-users-created are expected to work by default.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Enable Internal Admin API Access separately from Public access.
* Add Config variable for Draupnir Hijack command
And also make the internal admin API be automatically activated when this capability is used.
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Further Refine Internal Admin API
* Add Non Worker Labels for Internal Admin API
* Variable Rename
* Add validation rules for Internal Synapse admin API
* Add Draupnir Admin API required config validation.
* Override `matrix_synapse_reverse_proxy_companion_container_labels_internal_client_synapse_admin_api_traefik_entrypoints` via group vars
* Wire `matrix_bot_draupnir_admin_api_enabled` to `matrix_bot_draupnir_config_admin_enableMakeRoomAdminCommand` in Draupnir's `defaults/main.yml`
* Remove unnecessary `matrix_bot_draupnir_admin_api_enabled` override from `group_vars/matrix_servers`
The same value is now (more appropriately) defined in Draupnir's `defaults/main.yml` file anyway.
* Add additional condition (`matrix_bot_draupnir_enabled`) for enabling `matrix_synapse_container_labels_internal_client_synapse_admin_api_enabled`
* Use a separate task for validating `matrix_bot_draupnir_admin_api_enabled` when `matrix_bot_draupnir_config_admin_enableMakeRoomAdminCommand`
The other task deals with checking for null and not-blank and can't handle booleans properly.
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update D4A Configuration
D4A had some breaking config changes so this commit fixes them and gets us back into compliance with upstream. And since we run in a docker container we can use the /data/storage default.
* Update D4A Configuration to harmonise with bot mode
Change the default config for D4A to align with bot mode default in mdad. This should also avert a bit of a mess of a potential bug.
* Change D4A Room State Backing Store variable name and fix SPDX Headers
* Align D4A config with new schema
* Fix D4A Config Lint Error
* Update D4A SPDX Entries
* Do not use double quotes around `to_json` values
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Without this, we get a warning message from Traefik:
> INF Could not create a router for the container: too many services providerName=docker
Possibly due to the multiple services defined there without a single
explicitly-defined router.
Newer Element Web versions allow for the nginx port to be
overriden, etc., and provide instructions for running in read-only mode.
This makes our custom `nginx.conf` patches unnecessary.
Passing the correct `ELEMENT_WEB_PORT` environment variable
also helps with future changes.
Another benefit of this (besides keeping closer to upstream
recommendations and the improved simplicity) is that:
- the container can run its entrypoint env-substitutions code now,
without reporting errors
- IPv6 for nginx works, so `matrix-client-element:8080` is accessible
via IPv6 on the container network now
(this affects only for Traefik's communicaton with Element Web
internally; public connectivity was handled by Traefik and IPv6 was
available there even before)
Ref:
- 2052080d7d/docs/install.md (docker)
- https://github.com/element-hq/element-web/pull/28849
- https://github.com/element-hq/element-web/pull/28840
This reverts commit 178f7a9fff.
Element v1.11.95 doesn't seem to work. The container starts and is
unhealthy.
Until this is investigated and fixed, reverting.
* Update docs/configuring-playbook-ntfy.md: adopt the same description format as documentation for Jitsi and Etherpad
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ntfy.md: introduction and other edits
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ntfy.md: fix the link to the ansible-role-ntfy's documentation
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ntfy.md: edit the list item
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ntfy.md: the section for the web app
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ntfy.md: re-add the note about subscribing to a notification topic
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs: links to MASH project and its components
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ntfy.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-ntfy.md: create a section for the web app
- Remove the reasoning on why the web app is disabled by default as it is uncommon among the playbook's documentation
- Add the link to the official documentation about using the web app
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Based on eac4201a02/docs/configuring-exim-relay.md
- Add instruction to enable DKIM
- Replace the recommendation to use another SMTP server as relay, as DKIM has become available on exim-relay and configuring it greatly improves deliverability
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Since nginx 1.27.3, we can make use of the `resolve` parameter for an `upstream`'s `server`,
to allow DNS resolution to happen continuously at runtime, not just once during startup.
Previously, this was not possible to do in an `upstream` block without
an nginx-plus subscription. Outside of an `upstream` block, we've used
and still use `set $backend ..` workarounds to get DNS resolution at
runtime, but now we can do it in `upstream` as well.
This commit adds the hint to fetch Ansible roles which have been replaced, as it is pretty easy to overlook necessity of doing so, especially if you had not enabled (and disabled thereafter) roles, whose variable names has been changed.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
As there are not other instances where an abbreviation is written along with the service's full name, it is sensible to remove them from there.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Apparently those Markdown files are not expected to have something before the three hyphens on the top.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Move the recommendation to avoid installing ma1sd from configuring-playbook-ldap-auth.md to configuring-playbook-rest-auth.md
It has been long since recommending to install ma1sd was stopped, and the warning message is placed on the documentation about installing ma1sd as well, so it does not really seem to be sensible to advertise the component by repeating the warning… The message can rather be reused on the latter, as it is expected to be implemented with a backend such as ma1sd (see: matrix_synapse_ext_password_provider_rest_auth_endpoint on the file)
- Add instruction to install the component to configuring-playbook-ldap-auth.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Until now, most sections were specifying their own values for these.
For `client_max_body_size`, a value of 25MB was hardcoded in most places.
This was generally OK, but..
Some sections (those generated by the `render_locations_to_upstream` macro), were not specifying these options
and were ending up with a default value for configuration options for `client_max_body_size` (likely 1MB), etc.
From now on:
- we use individual variables for defining these for the Client-Server
and Federation API and apply these once at the `server` level
- we keep auto-determining the `client_max_body_size` for the
Client-Server API based on `matrix_synapse_max_upload_size_mb`
- we keep auto-calculating the `client_max_body_size` for the Federation
API based on the one for the Client API, but now also add a "minimum"
value (`matrix_synapse_reverse_proxy_companion_federation_api_client_max_body_size_mb_minimum: 100`)
to ensure we don't go too low
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/4100
The new baibot version (v1.5.0) supports the new Claude Sonnet 3.7
model, which is supposedly improved and priced the same way, so it makes
sense to upgrade to it in our static definitions.
This commit adds copyright attributions in SPDX to the files for matrix-cactus-comments and matrix-cactus-comments-client, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for matrix-client-cinny, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for matrix-client-fluffychat, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for matrix-conduwuit, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for prometheus-nginxlog-exporter, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for go-skype-bridge, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for matrix-reminder-bot, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
We previously made "this playbook" a link to some specific component.
This is somewhat misleading. Reading the text and seeing that "this playbook"
is a link, one might think that "this playbook" actually links to the
playbook's home page or something, not to the specific component which
could be "installed using this playbook".
This patch adjusts the markup so that the whole phrase "installed using this playbook"
is turned into a link (to the specific component's page). This makes it
more obvious where we're linking.
This work was initially done for the Email2Matrix docs page in
1b05343aba. This patch brings the same
change to all other instances.
From 3.1.4 and onward, container images will be published to ghcr.io instead of docker.io.
These images are built for arm64 and amd64, but not for arm32 anymore.
This commit adds copyright attributions in SPDX to the files for matrix-registration following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for matrix-client-hydrogen following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX to the files for matrix-bridge-appservice-kakaotalk following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX format to the files for matrix-bridge-wechat following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX format to the files for matrix-ma1sd following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX format as of 6aa320e117 to the files for matrix-bridge-mautrix-instagram, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attributions in SPDX format as of 6aa320e117 to the files for matrix-bridge-mautrix-facebook, following REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attirbutions in SPDX format to files for matrix-bot-chatgpt, following the REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attirbutions in SPDX format to files for matrix-bot-go-neb, following the REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attirbutions in SPDX format to files for matrix-sliding-sync, following the REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attirbutions in SPDX format to files for matrix-dimension, following the REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright attirbutions in SPDX format to files for matrix-email2matrix, following the REUSE's specification. ".license" files are added for config.json.j2 and matrix-email2matrix.service.j2.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright headers to Markdown, YAML, and labels.j2 files. For the rest of the files, which are ones in YAML and JSON files with the extention ".j2", ".license" files are added following the REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
`matrix_container_global_registry_prefix_override` may look similar to
the old `matrix_container_global_registry_prefix` variable
(removed in d6bf789710), but it's different.
The old `matrix_container_global_registry_prefix` variable was just a hardcode of `docker.io/` and roles that
needed to refer to `docker.io/` could use it. However, this was:
- not used by all roles, because some need another registry (not `docker.io/`)
- used only by roles within the playbook (`roles/custom`), not external roles
Overriding the old `matrix_container_global_registry_prefix` variable was rather pointless,
as it didn't cover everything.
The new `matrix_container_global_registry_prefix_override` variable, on the other hand,
lets you override the registry prefix for all components, regardless of whether they
use `docker.io/` or another registry by default.
This is useful to people who have somehow mirrored all container images to their own registry,
as it provides them with a single variable they can flip to influence the whole playbook.
This:
- brings consistency - no more mixing `_name_prefix` and `_registry_prefix`
- adds extensibility - a future patch will allow reconfiguring all registry prefixes for all roles in the playbook
We still have `_docker_` vs `_container_` inconsistencies.
These may be worked on later.
This commit changes ansible.md title and adds a link to the page on docs/README.md to improve discoverability of the guide a little bit.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This is done for a few reasons:
- less globals and more indepdendence for each role is better. We rely
on various externally-hosted roles and they don't rely on this global
either.
- `matrix_container_global_registry_prefix` could make people think they
could just override this variable and have all their images pull from
elsewhere. This is rarely the case, unless you've taken special care
to mirror all the various components (from their respective
registries) to your own. In such a case, you probably know what you're
mirroring and can adjust individual variables.
- nowadays, various components live on different registries.
With Docker Inc tightening rate limits for Docker Hub, it's even more
likely that we'll see increased diversity in where images are hosted
Those authors were picked up based on the current status (dae0f44603), the others (around 30 people whose contributions have been removed) being grouped as "MDAD project contributors".
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
As the future for the MX bridges in this playbook and by themselves seems uncertain, this commit adds license information in SPDX format to the files for those bridges, before the bridges would be deprecated and possibly get removed from the project.
Please note that .license files are added for the files which would be broken if such information are added as header, following the REUSE's specification.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Related to ac26cc1cb0 which disabled
`3478/udp` by default.
Without this patch, homeservers continued to advertise the `3478/udp` port,
even though it was no longer exposed. While clients should handle that
gracefully (by falling back to TCP, etc.), it seems like Element either
doesn't do that or it doesn't support TCP (which this patch won't fix).
In any case, it's better to only announce what is actually supported/exposed.
mautrix bridges run in appservice mode and create their own user
automatically. There's no need for `ensure-matrix-users-created`.
This patch only fixes the mautrix-blusky bridge's documentation.
The original author can be seen here: 66a812d99c12cb24f38f57fb271875ca80a9d4cc/docs/installing.md#L12-L35
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit adds copyright headers to the same kind of docs as ones linked from e48af8a327/docs/README.md, so that these files can be reused over there.
- docs/README.md
- prerequisites.md
- configuring-dns.md
- getting-the-playbook.md
- configuring-playbook.md
- maintenance-upgrading-services.md
- maintenance-and-troubleshooting.md
- uninstalling.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
ma1sd has not been installed by default since 958d089b68, so it seems that the variable does not need to be mentioned here.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- The section about enabling Gravater service is not removed as it is specific to configuring Jitsi on a Matrix server.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Add links to the role at MASH project and its document
- Replace common instructions with the links to the role at MASH project
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* This push request is about handling Traefik ipallowlist to synapse-admin application.
It's my first push request. If I forgot something please let me know. :-)
* Changed position of variable and naming for better expandebility of traefik options
* Remove useless `noqa var-naming` comment and too many blank lines at the end of the file
---------
Co-authored-by: AkDk7 <joerg@pannbacker.email>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Now that the document for setting up BorgBackup has been moved to the MASH project (https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg) it is sensible to remove the details in favor of it.
Because it may as well be noted that the document becomes available locally once the Ansible role is fetched, I think the document itself should not be deleted from the repository.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
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
Because all Element clients (Element Web and Element X mobile) now embed and use their own Element Call frontend application (and not the one hosted via the playbook), it makes little sense for the playbook to self-host the Element Call frontend for you. Setting up the frontend requires an additional hostname (DNS setup) and it won't be used by Element clients anyway, so **we now recommend not installing the Element Call frontend**.
💡 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 now lets you [Decide between Element Call vs just the Matrix RTC stack](./docs/configuring-playbook-element-call.md#decide-between-element-call-vs-just-the-matrix-rtc-stack).
If you've already installed Element Call (via `matrix_element_call_enabled: true`), you can switch to installing just the [Matrix RTC (Real-Time Communication) stack](./docs/configuring-playbook-matrix-rtc.md) (all supporting services **without the Element Call frontend**) by:
1. Adjusting your `vars.yml` configuration like this:
```diff
-matrix_element_call_enabled: true
+matrix_rtc_enabled: true
```
2. [Re-running the playbook](./docs/installing.md) with the `setup-all` Ansible tag (e.g. `just setup-all`)
3. Getting rid of the `call.element.example.com` DNS record
# 2025-03-15
## Element Call support
The playbook now supports [Element Call](https://github.com/element-hq/element-call) as an optional feature. Thanks to [wjbeckett](https://github.com/wjbeckett) for getting us started via [PR#3562](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3562).
Element Call is a native Matrix video conferencing application developed by [Element](https://element.io/) that has the goal of replacing [Jitsi](./docs/configuring-playbook-jitsi.md) and the old WebRTC stack used in previous Element versions.
💡 For now, Element Call is only supported with the [Synapse](docs/configuring-playbook-synapse.md) homeserver (with [federation](docs/configuring-playbook-federation.md) enabled) and [Element Web](docs/configuring-playbook-client-element-web.md) and Element X mobile clients. See the [Prerequisites](docs/configuring-playbook-element-call.md#prerequisites) section of the [Element Call documentation](docs/configuring-playbook-element-call.md) for more details.
To get started, see the [Configuring Element Call](docs/configuring-playbook-element-call.md) documentation page.
# 2025-03-08
## 6️⃣ IPv6 support enablement recommended by default
Our [default example configuration](./examples/vars.yml) and [Configuring DNS](./docs/configuring-dns.md) guides now recommend enabling [IPv6](https://en.wikipedia.org/wiki/IPv6) support. We recommend that everyone enables IPv6 support for their Matrix server, even if they don't have IPv6 connectivity yet.
Our new [Configuring IPv6](./docs/configuring-ipv6.md) documentation page has more details about the playbook's IPv6 support.
**Existing playbook users** will **need to do some manual work** to enable IPv6 support. This consists of:
- enabling IPv6 support for the Docker container networks:
- add `devture_systemd_docker_base_ipv6_enabled: true` to their `vars.yml` configuration file
- stop all services (`just stop-all`)
- delete all container networks on the server: `docker network rm $(docker network ls -q)`
- re-run the playbook fully: `just install-all`
- [configuring IPv6 (`AAAA`) DNS records](./docs/configuring-ipv6.md#configuring-dns-records-for-ipv6)
# 2025-02-26
## 🪦 Bye-bye, Email2Matrix
The [Email2Matrix](./docs/configuring-playbook-email2matrix.md) service has been superseded by the [Postmoogle](./docs/configuring-playbook-bridge-postmoogle.md) bridge for a long time now and was completely removed from the playbook today.
If you still have the Email2Matrix component installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually as described in the [Uninstalling Email2Matrix manually](./docs/configuring-playbook-email2matrix.md#uninstalling-email2matrix-manually) section of the documentation. The playbook will warn you if there are any `matrix_email2matrix_*` variables still remaining in your configuration.
# 2025-02-23
## The playbook defaults to exposing the Coturn STUN port (3478) over UDP once again
Recently, we made the playbook [default to exposing the Coturn STUN port (3478) only over TCP](#the-playbook-now-defaults-to-exposing-the-coturn-stun-port-3478-only-over-tcp) to reduce the severity of DDoS amplification/reflection attacks.
It seems like old Element clients on mobile devices only support talking to the STUN port over UDP, not TCP.
To accommodate such ancient clients, we're now **reversing this change** and **defaulting to exposing the Coturn STUN port (3478) over UDP once again**.
In light of this new information, you have 2 options:
1.**If you already adapted to the previous change and would like to adapt to this change one again**:
- make sure the `3478/udp` port is whitelisted in your external firewall (if you have one) once again.
2.**If you don't care about old Element clients and wish to reduce the severity of DDoS amplification/reflection attacks**:
- Consider closing the STUN/UDP port with the following configuration:
- Consider keeping `3478/udp` blocked in your external firewall (if you have one)
# 2025-02-21
## Docker daemon options are no longer adjusted when IPv6 is enabled
We landed [initial IPv6 support](#initial-work-on-ipv6-support) in the past via a `devture_systemd_docker_base_ipv6_enabled` variable that one had to toggle to `true`.
This variable did **2 different things at once**:
- ensured that container networks were created with IPv6 being enabled
- adjusted the Docker daemon's configuration to set `experimental: true` and `ip6tables: true` (a necessary prerequisite for creating IPv6-enabled networks)
Since Docker 27.0.1's [changes to how it handles IPv6](https://docs.docker.com/engine/release-notes/27/#ipv6), **adjusting the Docker daemon's configuration is no longer necessary**, because:
- `ip6tables` defaults to `true` for everyone
- `ip6tables` is out of the experimental phase, so `experimental` is no longer necessary
In light of this, we're introducing a new variable (`devture_systemd_docker_base_ipv6_daemon_options_changing_enabled`) for controlling if IPv6 should be force-enabled in the Docker daemon's configuration options.
Since most people should be on a modern enough Docker daemon version which doesn't require such changes, this variable defaults to `false`.
This change affects you like this:
- ✅ if you're **not explicitly enabling IPv6** (via `devture_systemd_docker_base_ipv6_enabled` in your configuration): you're unaffected
- ❓ if you're **explicitly enabling IPv6** (via `devture_systemd_docker_base_ipv6_enabled` in your configuration):
- ✅ .. and you're on a modern enough Docker version (which you most likely are): the playbook will no longer mess with your Docker daemon options. You're unaffected.
- 🔧 .. and you're on an old Docker version, you **are affected** and need to use the following configuration to restore the old behavior:
```yml
# Force-enable IPv6 by changing the Docker daemon's options.
# This is necessary for Docker < 27.0.1, but not for newer versions.
# Request that individual container networks are created with IPv6 enabled.
devture_systemd_docker_base_ipv6_enabled: true
```
## Support for bridging to Bluesky via mautrix-bluesky
Thanks to [Zepmann](https://github.com/Zepmann), the playbook now supports bridging to [Bluesky](https://bsky.app/) via [mautrix-bluesky](https://github.com/mautrix/bluesky).
To learn more, see our [Setting up mautrix-bluesky](./docs/configuring-playbook-bridge-mautrix-bluesky.md) documentation page.
# 2025-02-19
## The playbook now defaults to exposing the Coturn STUN port (3478) only over TCP
We've previously done some work to **decrease the severity** of DDoS amplification attacks done through the [Coturn](./docs/configuring-playbook-turn.md)'s STUN port (2.8x -> 1.6x) as reported in [coturn: Lower DDoS amplification/reflection factor from 2.8 to 1.6 #2592](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2592).
To **completely eliminate the problem** of DDoS amplification attacks done through the [Coturn](./docs/configuring-playbook-turn.md) STUN port even further (read more about this in [this article](https://stormwall.network/resources/blog/protect-against-ddos-based-on-stun-exploit)), the playbook now **disables exposure of the Coturn STUN port (`3478`) over UDP**. This is a bit heavy-handed, but is probably the only way to completely eliminate the problem.
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`.
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:
> 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
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.
To learn more, see our [Setting up FluffyChat Web](docs/configuring-playbook-client-fluffychat-web.md) documentation page.
# 2025-02-03
## The mautrix-hangouts bridge has been removed from the playbook
@ -13,7 +192,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 definining `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 defining `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:
@ -239,8 +418,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:
@ -566,7 +745,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 intruducing 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 introducing 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.
@ -649,7 +828,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 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.
**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.
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.
Thanks to [foxcris](https://github.com/foxcris), the playbook can now make automated local Postgres backups on a fixed schedule using [docker-postgres-backup-local](https://github.com/prodrigestivill/docker-postgres-backup-local).
Additional details are available in [Setting up postgres backup](docs/configuring-playbook-postgres-backup.md).
Additional details are available in [Setting up Postgres backup](docs/configuring-playbook-postgres-backup.md).
# 2021-04-03
@ -2672,7 +2851,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 requried 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 required 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.
@ -2704,7 +2883,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 accoring
`mapping` to your configuration, you will need to update it according
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
@ -2867,7 +3046,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 overriden 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 overridden by changing the `matrix_synapse_allow_public_rooms_without_auth` and `matrix_synapse_allow_public_rooms_over_federation` variables, respectively.
# 2019-10-05
@ -3421,7 +3600,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 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.
- `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.
- 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`)
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 reenable TLSv1 if you need to access Riot in older browsers.
You may wish to re-enable 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.
[](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com) [](https://liberapay.com/s.pantaleev/donate)
[](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
@ -53,6 +53,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) |
| [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) |
| [continuwuity](https://continuwuity.org) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. continuwuity is a continuation of conduwuit. | [Link](docs/configuring-playbook-continuwuity.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
@ -65,6 +66,7 @@ Web clients for Matrix that you can host on your own domains.
| [Hydrogen](https://github.com/element-hq/hydrogen-web) | ❌ | Lightweight Matrix client with legacy and mobile browser support | [Link](docs/configuring-playbook-client-hydrogen.md) |
| [Cinny](https://github.com/ajbura/cinny) | ❌ | Simple, elegant and secure web client | [Link](docs/configuring-playbook-client-cinny.md) |
| [SchildiChat Web](https://schildi.chat/) | ❌ | Based on Element Web, with a more traditional instant messaging experience | [Link](docs/configuring-playbook-client-schildichat-web.md) |
| [FluffyChat Web](https://fluffychat.im/) | ❌ | The cutest messenger in Matrix | [Link](docs/configuring-playbook-client-fluffychat-web.md) |
### Server Components
@ -79,6 +81,8 @@ Services that run on the server to make the various parts of your installation w
| [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) |
### Authentication
@ -91,7 +95,7 @@ Extend and modify how users are authenticated on your homeserver.
| [matrix-ldap-registration-proxy](https://gitlab.com/activism.international/matrix_ldap_registration_proxy) (advanced) | ❌ | Proxy that handles Matrix registration requests and forwards them to LDAP | [Link](docs/configuring-playbook-matrix-ldap-registration-proxy.md) |
| [matrix-registration](https://github.com/ZerataX/matrix-registration) | ❌ | Simple python application to have a token based Matrix registration | [Link](docs/configuring-playbook-matrix-registration.md) |
| [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service) (UVS) | ❌ | Service to verify details of a user based on an Open ID token | [Link](docs/configuring-playbook-user-verification-service.md) |
| [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service) | ❌ | Service to verify details of a user based on an Open ID token | [Link](docs/configuring-playbook-user-verification-service.md) |
| [mautrix-wsproxy](https://github.com/mautrix/wsproxy) | ❌ | Bridge to Android SMS or Apple iMessage | [Link](docs/configuring-playbook-bridge-mautrix-wsproxy.md) |
| [mautrix-meta](https://github.com/mautrix/instagram) | ❌ | Bridge to [Messenger](https://messenger.com/) and [Instagram](https://instagram.com/) | Link for [Messenger](docs/configuring-playbook-bridge-mautrix-meta-messenger.md) / [Instagram](docs/configuring-playbook-bridge-mautrix-meta-instagram.md) |
@ -183,6 +188,7 @@ Various services that don't fit any other categories.
2023 was a year filled with many changes for matrix-docker-ansible-deploy. In this post, we're looking backward at some of the major changes that happened this year, as well as taking a glimpse of what's ahead in 2024.
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 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:
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:
* 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.
# This script rebuilds the mautrix-meta-instagram Ansible role, using the mautrix-meta-messenger role as a source.
@ -32,7 +37,17 @@ done
sed --in-place 's/matrix_mautrix_meta_instagram_meta_mode: \(.*\)/matrix_mautrix_meta_instagram_meta_mode: instagram/g'$instagram_role_path/defaults/main.yml
sed --in-place 's/matrix_mautrix_meta_instagram_identifier: \(.*\)/matrix_mautrix_meta_instagram_identifier: matrix-mautrix-meta-instagram/g'$instagram_role_path/defaults/main.yml
echo"This bridge role is derived from the matrix-mautrix-meta-messenger Ansible role via automatic changes (see \`just rebuild-mautrix-meta-instagram\` or \`bin/rebuild-mautrix-meta-instagram.sh\`)." >> $instagram_role_path/README.md
This playbook is meant to be run using [Ansible](https://www.ansible.com/).
@ -29,7 +38,7 @@ If using the `pip` method, do note that the `ansible-playbook` binary may not be
## Using Ansible via Docker
Alternatively, you can run Ansible inside a Docker container (powered by the [devture/ansible](https://hub.docker.com/r/devture/ansible/) Docker image).
Alternatively, you can run Ansible inside a Docker container (powered by the [ghcr.io/devture/ansible](https://github.com/devture/docker-ansible/pkgs/container/ansible) Docker image).
This ensures that:
@ -49,50 +58,54 @@ Once you have a working Docker installation on the server, **clone the playbook*
You would then need to add `ansible_connection=community.docker.nsenter` to the host line in `inventory/hosts`. This tells Ansible to connect to the "remote" machine by switching Linux namespaces with [nsenter](https://man7.org/linux/man-pages/man1/nsenter.1.html), instead of using SSH.
Alternatively, you can leave your `inventory/hosts` as is and specify the connection type in **each**`ansible-playbook` call you do later, like this: `ansible-playbook --connection=community.docker.nsenter …`
Alternatively, you can leave your `inventory/hosts` as is and specify the connection type in **each**`ansible-playbook` call you do later, like this: `just install-all --connection=community.docker.nsenter` (or `ansible-playbook --connection=community.docker.nsenter …`).
Run this from the playbook's directory:
```sh
docker run -it --rm \
docker run \
-it \
--rm \
--privileged \
--pid=host \
-w /work \
-v `pwd`:/work \
--mount type=bind,src=`pwd`,dst=/work \
--entrypoint=/bin/sh \
docker.io/devture/ansible:2.18.1-r0-2
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.
The above command tries to mount an SSH key (`$HOME/.ssh/id_rsa`) into the container (at `/root/.ssh/id_rsa`). If your SSH key is at a different path (not in `$HOME/.ssh/id_rsa`), adjust that part.
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.
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.
Finally, you execute `ansible-playbook …` commands as per normal now.
Finally, you execute `just` or `ansible-playbook …` commands as per normal now.
#### If you don't use SSH keys for authentication
If you don't use SSH keys for authentication, simply remove that whole line (`-v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa:ro`).
If you don't use SSH keys for authentication, simply remove that whole line (`--mount type=bind,src$HOME/.ssh/id_ed25519,dst=/root/.ssh/id_ed25519,ro`).
To authenticate at your server using a password, you need to add a package. So, when you are in the shell of the ansible docker container (the previously used `docker run -it …` command), run:
@ -104,7 +117,7 @@ Then, to be asked for the password whenever running an `ansible-playbook` comma
#### Resolve directory ownership issues
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:
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:
> fatal: unsafe repository ('/work' is owned by someone else)
<sup>[Prerequisites](prerequisites.md) > Configuring your DNS settings > [Getting the playbook](getting-the-playbook.md) > [Configuring the playbook](configuring-playbook.md) > [Installing](installing.md)</sup>
SPDX-License-Identifier: AGPL-3.0-or-later
-->
# Configuring DNS settings
<sup>[Prerequisites](prerequisites.md) > Configuring DNS settings > [Getting the playbook](getting-the-playbook.md) > [Configuring the playbook](configuring-playbook.md) > [Installing](installing.md)</sup>
To set up Matrix on your domain, you'd need to do some DNS configuration.
@ -9,11 +26,14 @@ To set up Matrix on your domain, you'd need to do some DNS configuration.
To serve the base domain (`example.com`) and [Element Web](configuring-playbook-client-element-web.md) with the default subdomain, adjust DNS records as below.
| Type | Host | Priority | Weight | Port | Target |
As the table illustrates, you need to create 2 subdomains (`matrix.example.com` and `element.example.com`) and point both of them to your server's IP address (DNS `A` record or `CNAME` record is fine).
As the table illustrates, you need to create 2 subdomains (`matrix.example.com` and `element.example.com`) and point both of them to your server's IPv4/IPv6 address.
If you don't have IPv6 connectivity yet, you can skip the `AAAA` record. For more details about IPv6, see the [Configuring IPv6](./configuring-ipv6.md) documentation page.
The `element.example.com` subdomain is necessary, because this playbook installs the [Element Web](https://github.com/element-hq/element-web) client for you by default. If you'd rather instruct the playbook not to install Element Web (`matrix_client_element_enabled: false` when [Configuring the playbook](configuring-playbook.md) later), feel free to skip the `element.example.com` DNS record.
Since 2025-03-08, the [default example configuration](../examples/vars.yml) for the playbook recommends enabling [IPv6](https://en.wikipedia.org/wiki/IPv6) support for Docker's container networks.
**If you have IPv6 support on your server/network** (see [How do I check if my server has IPv6 connectivity?](#how-do-i-check-if-my-server-has-ipv6-connectivity)), then [enabling IPv6 support for the playbook](#enabling-ipv6-support-for-the-playbook) would give you:
- 📥 incoming IPv6 connectivity to the server via the server's IPv6 address/addresses (containers won't have their own individual publicly accessible IPs)
- 📤 outgoing IPv6 connectivity from the server via the server's IPv6 address/addresses (containers won't exit via their own individual IPv6 address)
- 🔄 IPv6 connectivity for cross-container communication
**If you still don't have IPv6 support on your server/network**, then enabling IPv6 support for the playbook will only enable IPv6 connectivity for cross-container communication and shouldn't affect your server's incoming/outgoing communication. You may also be interested in reading if [there's a performance penalty to enabling IPv6 if the server/network doesn't support IPv6 connectivity?](#is-there-a-performance-penalty-to-enabling-ipv6-if-the-server-network-doesn-t-support-ipv6-connectivity)
As such, **we recommend that you follow the default example configuration and leave IPv6 support for Docker enabled in all cases**.
Enabling IPv6 consists of 2 steps:
- [Enabling IPv6 support for the playbook](#enabling-ipv6-support-for-the-playbook)
- [Configuring DNS records for IPv6](#configuring-dns-records-for-ipv6)
💡 If you've followed a recent version of our documentation, you would have already done these steps, so there's nothing else to do.
## Enabling IPv6 support for the playbook
You can enable IPv6 support for all components' Docker container networks by using the following `vars.yml` configuration:
```yml
# Controls whether container networks will be created with IPv6 support.
#
# If you also have IPv6 support on your server/network and AAAA DNS records pointing to the server,
# enabling this will effectively give you full public IPv6 connectivity (powered by NAT66).
#
# We recommend leaving this enabled even if you don't currently have IPv6 connectivity on your server/network.
# This way, once you eventually get IPv6 connectivity, you won't have to change anything (besides DNS records).
#
# Flipping this setting later on requires manual work (stopping services, deleting and recreating all container networks).
#
# In the future, this setting will likely default to `true`, so if you really want IPv6 disabled, explicitly set this to `false`.
#
# People managing Docker themselves and running an older Docker version will need additional configuration.
#
# Learn more in `docs/configuring-ipv6.md`.
devture_systemd_docker_base_ipv6_enabled:true
```
Doing this:
- all container networks will be IPv6-enabled
- NAT66 will be used, so that:
- containers will get [Unique Local Addresses (ULA)](https://en.wikipedia.org/wiki/Unique_local_address)
- the outgoing IPv6 address for containers will be the same as the one on the server
- traffic destined for the IPv6 address of the server will be forwarded to the containers that handle (and publish) that specific port
> [!WARNING]
> Without enabling this and assuming you have IPv6 `AAAA` DNS records pointing to the server (see [Configuring DNS records for IPv6](#configuring-dns-records-for-ipv6)), IPv6 traffic will still be handled, but NAT64 will be used instead of NAT66.
> As such, containers will only have an IPv4 address and all IPv6 traffic that reaches them will seem to originate from a local IP. Containers also won't be able to make outgoing (even cross-container) IPv6 requests.
To confirm connectivity, see the following other resources:
- [How do I check if my server has IPv6 connectivity?](#how-do-i-check-if-my-server-has-ipv6-connectivity)
- [How do I check outgoing IPv6 connectivity for containers?](#how-do-i-check-outgoing-ipv6-connectivity-for-containers)
- [How do I check incoming IPv6 connectivity for containers?](#how-do-i-check-incoming-ipv6-connectivity-for-containers)
- [How do I confirm if my container networks are IPv6-enabled?](#how-do-i-confirm-if-my-container-networks-are-ipv6-enabled)
- Ensure that the [Federation Tester](https://federationtester.matrix.org/) reports that your server is reachable over IPv6.
## Configuring DNS records for IPv6
[Enabling IPv6 support for the playbook](#enabling-ipv6-support-for-the-playbook) tells you how to prepare for IPv6 on the container (Docker) side.
For full public IPv6 connectivity (and not just IPv6 connectivity for containers inside the container networks) you also need to **ensure that your domain names** (e.g. `matrix.example.com` and others) have IPv6 (`AAAA`) DNS records pointing to the server's IPv6 address.
Also see the [Configuring DNS settings](configuring-dns.md) documentation page for more details.
### A note about old Docker
With our [default example configuration](../examples/vars.yml), the playbook manages Docker for you and installs a modern-enough version.
Docker versions newer than 27.0.1 enable IPv6 integration at the Docker daemon level out of the box. This still requires that networks are created with IPv6 support as described in the [Enabling IPv6 support for the playbook](#enabling-ipv6-support-for-the-playbook) section above.
**If you're on an old Docker version** (Docker 27.0.0 or older) for some reason, it's likely that your Docker installation is not enabled for IPv6 at all. In such a case:
- if Docker is managed by the playbook, you can tell it to force-enable IPv6 via `devture_systemd_docker_base_ipv6_daemon_options_changing_enabled: true`
- if Docker is managed by you manually, you can add `{"experimental": true, "ip6tables": true}` to the Docker daemon options and restart the Docker service (`docker.service`).
### Frequently Asked Questions
#### How do I check if my server has IPv6 connectivity?
##### With curl
You can run `curl https://icanhazip.com` and see if it returns an [IPv6 address](https://en.wikipedia.org/wiki/IPv6_address) (an address with `:` characters in it, like `2001:db8:1234:5678::1`). If it does, then your server has IPv6 connectivity and prefers it over using IPv4. This is common.
If you see an IPv4 address instead (e.g. `1.2.3.4`), it may be that your server prefers IPv4 over IPv6 or that your network does not support IPv6. You can try forcing `curl` to use IPv6 by running `curl -6 https://icanhazip.com` and see if it returns an IPv6 address.
##### With other network utilities
You can run `ip -6 addr` to see if you have any IPv6 addresses assigned to your server, besides the link-local (`fe80::*`) addresses that everyone has (unless they have force-disabled IPv6 support on their system).
If you do have an IPv6 address, it's still worth [using curl](#with-curl) to confirm that your server can successfully make outgoing requests over IPv6.
#### What does the `devture_systemd_docker_base_ipv6_enabled` setting actually do?
The `devture_systemd_docker_base_ipv6_enabled` setting controls whether container networks will be created with IPv6 support.
Changing this setting subsequently requires manual work (deleting all container networks).
See [I've changed the `devture_systemd_docker_base_ipv6_enabled` setting, but it doesn't seem to have any effect](#i-ve-changed-the-devture_systemd_docker_base_ipv6_enabled-setting-but-it-doesn-t-seem-to-have-any-effect).
#### I've changed the `devture_systemd_docker_base_ipv6_enabled` setting, but it doesn't seem to have any effect.
If you're using an older Docker version (Docker 27.0.0 or older), see [A note about old Docker](#a-note-about-old-docker).
If you've previously installed with one `devture_systemd_docker_base_ipv6_enabled` value and then changed it to another, you need to:
- stop all services (`just stop-all`)
- delete all container networks on the server: `docker network rm $(docker network ls -q)`
- re-run the playbook fully: `just install-all`
#### How do I confirm if my container networks are IPv6-enabled?
You can list container networks by running `docker network ls` on the server.
For each container network (e.g. `matrix-homeserver`), you can check if it has IPv6 connectivity by running a command like this: `docker network inspect matrix-homeserver`.
Ensure that there's an IPv6 subnet/gateway in the `IPAM.Config` section. If yes, you may wish to proceed with [How do I check outgoing IPv6 connectivity for containers?](#how-do-i-check-outgoing-ipv6-connectivity-for-containers)
If there's no IPv6 subnet/gateway in the `IPAM.Config` section, this container network was not created with IPv6 support.
See [I've changed the `devture_systemd_docker_base_ipv6_enabled` setting, but it doesn't seem to have any effect](#i-ve-changed-the-devture_systemd_docker_base_ipv6_enabled-setting-but-it-doesn-t-seem-to-have-any-effect).
#### How do I check outgoing IPv6 connectivity for containers?
```sh
docker run --rm --network=matrix-homeserver quay.io/curl/curl:latest curl -6 https://icanhazip.com
```
💡 This one-off container is connected to the `matrix-homeserver` container network, not to the default Docker bridge network. The default Docker `bridge` network does not have IPv6 connectivity by default (yet) and is not influenced by the `devture_systemd_docker_base_ipv6_enabled` setting, so using that network (by omitting `--network=..` from the command above) will not show an IPv6 address
✅ If this command returns an IPv6 address, you're all good.
❌ If this command doesn't return an IPv6 address, it may be that:
- your container network does not have IPv6 connectivity. See [How do I confirm if my container networks are IPv6-enabled?](#how-do-i-confirm-if-my-container-networks-are-ipv6-enabled) for more details.
- your server does not have IPv6 connectivity. See [How do I check if my server has IPv6 connectivity?](#how-do-i-check-if-my-server-has-ipv6-connectivity) for more details. If you do have IPv6 connectivity, then the issue is with Docker's IPv6 configuration. Otherwise, you need to check your server's network configuration/firewall/routing and get back to configuring the playbook later on.
#### How do I check incoming IPv6 connectivity for containers?
Only containers that publish ports will be exposed (reachable) publicly on the server's own IPv6 address. Containers will not get their own individual public IPv6 address.
For this playbook, a commonly exposed container is the Traefik reverse-proxy container (unless [you're using your own webserver](./configuring-playbook-own-webserver.md)).
You can either do something like `curl -6 https://matrix.example.com` from an IPv6-enabled host (including the server itself) and see if it works.
An alternative is to use the [IPv6 Port Checker](https://port.tools/port-checker-ipv6/) with a hostname of `matrix.example.com` and a port of `443`.
💡 Trying to connect to `matrix.example.com` via IPv6 requires that you have already [configured the DNS records for IPv6](#configuring-dns-records-for-ipv6) as described above. If you wish to eliminate DNS as a potential issue, you can also try connecting to the server's own IPv6 address directly: `curl -6 -H 'Host: matrix.example.com' https://[2001:db8:1234:5678::1]` (we pass a `Host` header to tell Traefik which host we'd like it to serve).
#### Why enable IPv6 if my network doesn't support it yet?
Because when your network does get support for IPv6 later on (even if that's 5 years away), you won't have to change anything besides [configuring the DNS records for IPv6](#configuring-dns-records-for-ipv6).
#### Can I use a custom subnet for IPv6?
Not easily.
The playbook and the various roles only support passing an `enable_ipv6` flag (`true` or `false` value depending on the `devture_systemd_docker_base_ipv6_enabled` Ansible variable) when creating the Docker container networks.
There's no support for passing a custom subnet for IPv4 and IPv6. We let Docker auto-generate the subnets for us.
You can either create a Pull Request that adds support for this to the various playbook roles, or you can manually recreate the networks from the command-line (e.g. `docker network rm matrix-homeserver && docker network create --ipv6 --subnet=2001:db8:1234:5678::/64 matrix-homeserver`).
#### Can I use Global Unicast Addresses (GUA) for IPv6?
No. You cannot have GUA addresses where each container is individually addressable over the public internet.
The playbook only supports NAT66, which should be good enough for most use cases.
Having containers get IPv6 addresses from your own GUA subnet requires complex configuration (ndp-proxy, etc.) and is not supported.
You may find [this Reddit post](https://www.reddit.com/r/ipv6/comments/1alpzmb/comment/kphpw11/) interesting.
#### Is there a performance penalty to enabling IPv6 if the server/network doesn't support IPv6 connectivity?
Probably a tiny one, as services may try to make (unsuccessful) outgoing requests over IPv6.
# Setting up Prometheus Alertmanager integration via matrix-alertmanager-receiver (optional)
The playbook can install and configure the [matrix-alertmanager-receiver](https://github.com/metio/matrix-alertmanager-receiver) service for you. It's a [client](https://prometheus.io/docs/alerting/latest/clients/) for Prometheus' [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/), allowing you to deliver alerts to Matrix rooms.
@ -97,16 +105,12 @@ After configuring the playbook and potentially [adjusting your DNS records](#adj
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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 playbook can install and configure the Appservice Double Puppet service for you. It is a homeserver appservice through which bridges (and potentially other services) can impersonate any user on the homeserver.
@ -28,16 +35,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
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.
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.
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` recomendation. Using the chat is recomended.
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.
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))
@ -14,148 +14,6 @@ The playbook can install and configure [BorgBackup](https://www.borgbackup.org/)
BorgBackup is a deduplicating backup program with optional compression and encryption. That means your daily incremental backups can be stored in a fraction of the space and is safe whether you store it at home or on a cloud service.
## Prerequisites
### Set up a remote server for storing backups
You will need a remote server where BorgBackup will store the backups. There are hosted, BorgBackup compatible solutions available, such as [BorgBase](https://www.borgbase.com).
### Check the Postgres version
If you're using the integrated Postgres database server (as opposed to [an external Postgres server](configuring-playbook-external-postgres.md)), backups with BorgBackup will also include dumps of your Postgres database by default.
Unless you disable the Postgres-backup support, make sure that the Postgres version of your homeserver's database is compatible with borgmatic. You can check the compatible versions [here](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg/blob/main/defaults/main.yml).
An alternative solution for backing up the Postgres database is [postgres backup](configuring-playbook-postgres-backup.md). If you decide to go with another solution, you can disable Postgres-backup support for BorgBackup using the `backup_borg_postgresql_enabled` variable.
### Create a new SSH key
Run the command below on any machine to create a new SSH key:
**Note**: `REPO` will be initialized on backup start, for example: `matrix`. See [Remote repositories](https://borgbackup.readthedocs.io/en/stable/usage/general.html#repository-urls) for the syntax.
### Set backup archive name (optional)
You can specify the backup archive name format. To set it, add the following configuration to your `vars.yml` file (adapt to your needs):
It is also possible to configure a retention strategy. To configure it, add the following configuration to your `vars.yml` file (adapt to your needs):
```yaml
backup_borg_retention_keep_hourly:0
backup_borg_retention_keep_daily:7
backup_borg_retention_keep_weekly:4
backup_borg_retention_keep_monthly:12
backup_borg_retention_keep_yearly:2
```
### Edit the schedule (optional)
By default the task will run 4 a.m. every day based on the `backup_borg_schedule` variable. 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
backup_borg_schedule:"*-*-* 04:00:00"
```
**Note**: the actual job may run with a delay. See `backup_borg_schedule_randomized_delay_sec` [here](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg/blob/f5d5b473d48c6504be10b3d946255ef5c186c2a6/defaults/main.yml#L50) for its default value.
### Set include and/or exclude directories (optional)
`backup_borg_location_source_directories` defines the list of directories to back up. It's set to `{{ matrix_base_data_path }}` by default, which is the base directory for every service's data, such as Synapse, Postgres and the bridges.
You might also want to exclude certain directories or file patterns from the backup using the `backup_borg_location_exclude_patterns` variable.
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
- [backup_borg role](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg)'s [`defaults/main.yml`](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg/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 `backup_borg_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. -->
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 installation, `backup-borg` will run automatically every day at `04:00:00` (as defined in `backup_borg_schedule` by default).
### Manually start the task
Sometimes it can be helpful to run the backup as you'd like, avoiding to wait until 4 a.m., like when you test your configuration.
If you want to run it immediately, log in to the server with SSH and run `systemctl start matrix-backup-borg`.
This will not return until the backup is done, so it can possibly take a long time. Consider using [tmux](https://en.wikipedia.org/wiki/Tmux) if your SSH connection is unstable.
## 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 backup-borg`.
The [Ansible role for BorgBackup](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg) is developed and maintained by [the MASH (mother-of-all-self-hosting) project](https://github.com/mother-of-all-self-hosting). For details about configuring BorgBackup, you can check them via:
- 🌐 [the role's documentation at the MASH project](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg/blob/main/docs/configuring-backup-borg.md) online
- 📁 `roles/galaxy/backup_borg/docs/configuring-backup-borg.md` locally, if you have [fetched the Ansible roles](installing.md#update-ansible-roles)
By default, this playbook sets up services on your Matrix server (`matrix.example.com`), but has it configured so that it presents itself as the base domain (`example.com`). To have this server officially be responsible for Matrix services for the base domain (`example.com`), you need to set up server delegation / redirection.
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`.
# Setting up matrix-bot-chatgpt (optional, unmaintained)
**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.
**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.
The playbook can install and configure [matrix-chatgpt-bot](https://github.com/matrixgpt/matrix-chatgpt-bot) for you.
### Create and invite the bot to the management room
@ -133,9 +142,23 @@ Draupnir can receive reports in the management room.
The bot can intercept the report API endpoint of the client-server API, which requires integration with the reverse proxy in front of the homeserver. If you are using Traefik, this playbook can set this up for you:
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.
# 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.
@ -181,10 +204,16 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
**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.
- If you change the bot password (`matrix_bot_draupnir_password` in your `vars.yml` file) subsequently, the bot user's credentials on the homeserver won't be updated automatically. If you'd like to change the bot user's password, use a tool like [synapse-admin](configuring-playbook-synapse-admin.md) to change it, and then update `matrix_bot_draupnir_password` to let the bot know its new password.
## Usage
You can refer to the upstream [documentation](https://the-draupnir-project.github.io/draupnir-documentation/) for additional ways to use and configure Draupnir and for a more detailed usage guide.
@ -213,7 +242,7 @@ 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).
Polcy lists are maintained in Matrix rooms. A popular policy list is maintained in the public `#community-moderation-effort-bl:neko.dev` room.
Policy lists are maintained in Matrix rooms. A popular policy list is maintained in the public `#community-moderation-effort-bl:neko.dev` room.
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`
**Note**: [Go-NEB](https://github.com/matrix-org/go-neb) is now an archived (**unmaintained**) project. 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 bot instead of this one.
**Note**: [Go-NEB](https://github.com/matrix-org/go-neb) is now an archived (**unmaintained**) project. 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 bot instead of this one.
The playbook can install and configure [Go-NEB](https://github.com/matrix-org/go-neb) for you.
@ -235,16 +245,12 @@ After configuring the playbook and potentially [adjusting your DNS records](#adj
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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 playbook can install and configure [matrix-registration-bot](https://github.com/moan0s/matrix-registration-bot) for you.
@ -65,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 [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).
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).
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:
The playbook can install and configure the [Mjolnir](https://github.com/matrix-org/mjolnir) moderation bot for you.
@ -178,13 +189,11 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
- 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.
# Setting up Appservice Discord bridging (optional)
**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.
@ -43,16 +52,13 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- The `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
`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 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**: bridging to [IRC](https://en.wikipedia.org/wiki/Internet_Relay_Chat) can also happen via the [Heisenbridge](configuring-playbook-bridge-heisenbridge.md) bridge supported by the playbook.
@ -75,16 +84,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Appservice Kakaotalk bridging (optional)
The playbook can install and configure [matrix-appservice-kakaotalk](https://src.miscworks.net/fair/matrix-appservice-kakaotalk) for you, for bridging to [Kakaotalk](https://www.kakaocorp.com/page/service/service/KakaoTalk?lang=ENG). This bridge is based on [node-kakao](https://github.com/storycraft/node-kakao) (now unmaintained) and some [mautrix-facebook](https://github.com/mautrix/facebook) code.
@ -40,16 +49,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
@ -83,16 +94,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Appservice Webhooks bridging (optional, deprecated)
**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.
**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.
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.
@ -36,16 +47,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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 playbook can install and configure [beeper-linkedin](https://github.com/beeper/linkedin) for you, for bridging to [LinkedIn](https://www.linkedin.com/) Messaging. This bridge is based on the mautrix-python framework and can be configured in a similar way to the mautrix bridges.
@ -36,16 +46,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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 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.
@ -36,16 +43,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Heisenbridge bouncer-style IRC bridging (optional)
**Note**: bridging to [IRC](https://en.wikipedia.org/wiki/Internet_Relay_Chat) can also happen via the [matrix-appservice-irc](configuring-playbook-bridge-appservice-irc.md) bridge supported by the playbook.
@ -57,16 +65,12 @@ After configuring the playbook and potentially [adjusting your DNS records](#adj
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
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_'`).
@ -162,7 +167,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 metics.
Probably you wish to enable Grafana along with Prometheus for generating graphs of the metrics.
To enable Grafana, see [this section](configuring-playbook-prometheus-grafana.md#adjusting-the-playbook-configuration-grafana) for instructions.
The playbook can install and configure [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) for you.
@ -46,16 +54,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
The playbook can install and configure [mautrix-bluesky](https://github.com/mautrix/bluesky) for you, which provides a bridge to [Bluesky](https://bsky.social/about).
See the project's [documentation](https://github.com/mautrix/bluesky/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisite (optional)
### Enable Appservice Double Puppet
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 [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service 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.
## 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_bluesky_enabled:true
```
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
<!-- 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
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. -->
- 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 bridge, you need to start a chat with `@blueskybot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/bluesky/authentication.html).
After logging in, the bridge will create portal rooms for recent chats. Portal rooms for other chats will be created as you receive messages.
## 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-bluesky`.
### 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:
The playbook can install and configure various [mautrix](https://github.com/mautrix) bridges (twitter, discord, signal, googlechat, etc.), as well as many other (non-mautrix) bridges. This is a common guide for configuring mautrix bridges.
@ -15,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. **`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).
**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.
@ -144,16 +153,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -45,16 +57,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Mautrix Facebook bridging (optional, deprecated)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**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.
**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.
The playbook can install and configure [mautrix-facebook](https://github.com/mautrix/facebook) for you.
@ -38,16 +50,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Mautrix Google Messages bridging (optional)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -35,16 +43,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Mautrix Google Chat bridging (optional)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -37,16 +46,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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
@ -54,7 +59,7 @@ To use the bridge, you need to start a chat with `@googlechatbot:example.com` (w
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/googlechat/authentication.html).
After logging in, the bridge will create portal rooms for some recent chats. Portal rooms for other chats will be created as you receive messages.
After logging in, the bridge will create portal rooms for recent chats. Portal rooms for other chats will be created as you receive messages.
# Setting up Mautrix Hangouts bridging (optional, removed)
🪦 The playbook used to be able to install and configure [mautrix-hangouts](https://github.com/mautrix/hangouts), but no longer includes this component, because Google Hangouts has been discontinued since the 1st of November 2022.
# Setting up Mautrix Instagram bridging (optional, deprecated)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**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.
**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.
The playbook can install and configure [mautrix-instagram](https://github.com/mautrix/instagram) for you.
@ -28,16 +37,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Instagram bridging via Mautrix Meta (optional)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -51,16 +58,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Messenger bridging via Mautrix Meta (optional)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -64,16 +72,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -40,16 +56,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -45,16 +54,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -75,16 +88,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -37,16 +46,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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
@ -54,7 +59,7 @@ To use the bridge, you need to start a chat with `@twitterbot:example.com` (wher
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/twitter/authentication.html).
After logging in, the bridge will create portal rooms for some recent chats. Portal rooms for other chats will be created as you receive messages.
After logging in, the bridge will create portal rooms for recent chats. Portal rooms for other chats will be created as you receive messages.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -36,16 +49,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up Mautrix wsproxy for bridging Android SMS or Apple iMessage (optional)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
@ -53,20 +61,16 @@ After configuring the playbook and potentially [adjusting your DNS records](#adj
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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
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).
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).
# Setting up MX Puppet Discord bridging (optional)
**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.
@ -22,16 +31,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up MX Puppet GroupMe bridging (optional)
The playbook can install and configure [mx-puppet-groupme](https://gitlab.com/xangelix-pub/matrix/mx-puppet-groupme) for you.
@ -18,16 +27,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up MX Puppet Instagram bridging (optional)
The playbook can install and configure [mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram) for you.
@ -18,16 +25,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up MX Puppet Skype bridging (optional, removed)
🪦 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.
**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.
@ -27,16 +38,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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 playbook can install and configure [mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) for you.
@ -18,16 +27,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
# Setting up MX Puppet Twitter bridging (optional)
**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.
@ -29,16 +37,12 @@ After configuring the playbook, run it with [playbook tags](playbook-tags.md) as
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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 playbook can install and configure [matrix-wechat](https://github.com/duo/matrix-wechat) for you, for bridging to [WeChat](https://www.wechat.com/).
The playbook can install and configure the [Cactus Comments](https://cactus.chat) system for you.
@ -77,16 +86,12 @@ After configuring the playbook and potentially [adjusting your DNS records](#adj
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- 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.
`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.
By default, this playbook installs the [Element Web](https://github.com/element-hq/element-web) Matrix client for you. If that's okay, you can skip this document.
The playbook can install and configure the [FluffyChat Web](https://github.com/krille-chan/fluffychat) Matrix client for you.
FluffyChat Web is a cute cross-platform (web, iOS, Android) messenger for Matrix written in [Flutter](https://flutter.dev/).
💡 **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://fluffychat.im/) developers
## Adjusting DNS records
By default, this playbook installs FluffyChat Web on the `fluffychat.` subdomain (`fluffychat.example.com`) and requires you to create a CNAME record for `fluffychat`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable FluffyChat Web, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
matrix_client_fluffychat_enabled:true
```
### Adjusting the FluffyChat Web URL (optional)
By tweaking the `matrix_client_fluffychat_hostname` and `matrix_client_fluffychat_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 FluffyChat Web.
After changing the domain, **you may need to adjust your DNS** records to point the FluffyChat Web domain to the Matrix server.
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
## 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. -->
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
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-client-fluffychat`.
The playbook can install and configure the [conduwuit](https://conduwuit.puppyirl.gay/) Matrix server for you.
@ -11,6 +18,7 @@ By default, the playbook installs [Synapse](https://github.com/element-hq/synaps
> [!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
> - **the Conduwuit project appears to have been abandoned**. You may wish to install [Conduit](./configuring-playbook-conduit.md), or one of the Conduwuit successors (like [Continuwuity](configuring-playbook-continuwuity.md))
## Adjusting the playbook configuration
@ -76,6 +84,7 @@ Then, send its content to the existing admin room:
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 also supports.
> [!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.
# 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:
Unlike other homeserver implementations (like Synapse and Dendrite), continuwuity 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 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`.
The playbook can configure Dynamic DNS with [ddclient](https://github.com/ddclient/ddclient) for you. It is a Perl client used to update dynamic DNS entries for accounts on Dynamic DNS Network Service Provider.
@ -6,7 +14,7 @@ Most cloud providers / ISPs will charge you extra for a static IP address. If yo
## Prerequisite
You'll need to get a username and password from your DNS provider. Please consult with the provider about how to retrieve them.
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.
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
There are some additional things you may wish to configure about the component.
@ -49,7 +59,8 @@ The shortcut commands with the [`just` program](just.md) are also available: `ju
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`.
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`.
The playbook can install and configure [Element Call](https://github.com/element-hq/element-call) and its supporting components that are part of the [Matrix RTC stack](configuring-playbook-matrix-rtc.md).
Element Call is a native Matrix video conferencing application developed by [Element](https://element.io), designed for secure, scalable, privacy-respecting, and decentralized video and voice calls over the Matrix protocol. Built on MatrixRTC ([MSC4143](https://github.com/matrix-org/matrix-spec-proposals/pull/4143)), it utilizes [MSC4195](https://github.com/hughns/matrix-spec-proposals/blob/hughns/matrixrtc-livekit/proposals/4195-matrixrtc-livekit.md) with [LiveKit Server](configuring-playbook-livekit-server.md) as its backend.
See the project's [documentation](https://github.com/element-hq/element-call) to learn more.
## 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)
- 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**.
## Decide between Element Call vs just the Matrix RTC stack
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.
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**.
| Description | Static website that provides the Element Call UI (but often embedded by clients) | Scalable, multi-user conferencing solution based on WebRTC | A helper component that allows Element Call to integrate with LiveKit Server |
| Required for Element Call to function | No | Yes | Yes |
| `matrix_rtc_enabled` | ❌ Not Installed, but usually unnecessary | ✅ Installed | ✅ Installed |
All documentation below assumes that you've decided to install Element Call and not just the Matrix RTC stack.
## Decide on a domain and path
By default, the Element Call frontend is configured to be served on the `call.element.example.com` domain.
If you'd like to run Element Call on another hostname, see the [Adjusting the Element Call URL](#adjusting-the-element-call-url-optional) section below.
## Adjusting DNS records
By default, this playbook installs Element Call on the `call.element.` subdomain (`call.element.example.com`) and requires you to create a `CNAME` record for `call.element`, which targets `matrix.example.com`.
When setting these values, replace `example.com` with your own.
All dependency services for Element Call ([LiveKit Server](configuring-playbook-livekit-server.md) and [Livekit JWT Service](configuring-playbook-livekit-jwt-service.md)) are installed and configured automatically by the playbook. By default, these services are installed on subpaths on the `matrix.` domain (e.g. `/livekit-server`, `/livekit-jwt-service`), so no DNS record adjustments are required for them.
## Adjusting firewall rules
In addition to the HTTP/HTTPS ports (which you've already exposed as per the [prerequisites](prerequisites.md) document), you'll also need to open ports required by [LiveKit Server](configuring-playbook-livekit-server.md) as described in its own [Adjusting firewall rules](configuring-playbook-livekit-server.md#adjusting-firewall-rules) section.
## Adjusting the playbook configuration
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
# Enable the Element Call frontend UI to allow standalone use of Element Call.
# Enabling this also auto-enables the Matrix RTC stack.
matrix_element_call_enabled:true
```
### Adjusting the Element Call URL (optional)
By tweaking the `matrix_element_call_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:
> 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:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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
Once installed, Element Call integrates seamlessly with Matrix clients like [Element Web](configuring-playbook-client-element-web.md) and Element X on mobile (iOS and Android).
By default, this playbook sets up an [Exim](https://www.exim.org/) email server through which all Matrix services send emails.
By default, this playbook sets up an [Exim](https://www.exim.org/) relay SMTP mailer service (powered by [exim-relay](https://github.com/devture/exim-relay) and the [ansible-role-exim-relay](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay) Ansible role), through which all Matrix services send emails.
The email server would attempt to deliver emails directly to their final destination. This may or may not work, depending on your domain configuration (SPF settings, etc.)
**With the default setting, exim-relay attempts to deliver emails directly with the address `matrix@matrix.example.com`**, as specified by the `exim_relay_sender_address` playbook variable. See below if you want to configure the playbook to relay email through another SMTP server.
By default, emails are sent from `matrix@matrix.example.com`, as specified by the `exim_relay_sender_address` playbook variable.
> [!WARNING]
> On some cloud providers (Google Cloud, etc.), [port 25 is always blocked](https://cloud.google.com/compute/docs/tutorials/sending-mail/), so sending email directly from your server is not possible. You will need to [relay email through another SMTP server](#relaying-email-through-another-smtp-server).
💡 To improve deliverability, we recommend [relaying email through another SMTP server](#relaying-email-through-another-smtp-server) anyway.
The [Ansible role for exim-relay](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay) is developed and maintained by [the MASH (mother-of-all-self-hosting) project](https://github.com/mother-of-all-self-hosting). For details about configuring exim-relay, you can check them via:
- 🌐 [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)
## Firewall settings
No matter whether you send email directly (the default) or you relay email through another host (see how below), you'll probably need to allow outgoing traffic for TCP ports 25/587 (depending on configuration).
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).
Docker automatically opens these ports in the server's firewall, so you likely don't need to do anything. If you use another firewall in front of the server, you may need to adjust it.
## Adjusting the playbook configuration
### Relaying email through another SMTP server
### Enable DKIM authentication to improve deliverability (optional)
If you'd like to relay email through another SMTP server, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
By default, exim-relay attempts to deliver emails directly. This may or may not work, depending on your domain configuration.
To improve email deliverability, you can configure authentication methods such as DKIM (DomainKeys Identified Mail), SPF, and DMARC for your domain. Without setting any of these authentication methods, your outgoing email is most likely to be quarantined as spam at recipient's mail servers.
For details about configuring DKIM, refer [this section](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay/blob/main/docs/configuring-exim-relay.md#enable-dkim-support-optional) on the role's documentation.
💡 If you cannot enable DKIM, SPF, or DMARC on your domain for some reason, we recommend relaying email through another SMTP server.
### Relaying email through another SMTP server (optional)
**On some cloud providers such as Google Cloud, [port 25 is always blocked](https://cloud.google.com/compute/docs/tutorials/sending-mail/), so sending email directly from your server is not possible.** In this case, you will need to relay email through another SMTP server.
For details about configuration, refer [this section](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay/blob/main/docs/configuring-exim-relay.md#relaying-email-through-another-smtp-server) on the role's document.
### Disable mail service (optional)
For a low-power server you might probably want to disable exim-relay. To do so, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
**Note**: only the secure submission protocol (using `STARTTLS`, usually on port `587`) is supported. **SMTPS** (encrypted SMTP, usually on port `465`) **is not supported**.
Note that disabling exim-relay will stop email-notifications and other similar functions from working.
### Sending emails using Sendgrid
See [this entry on the FAQ](faq.md#how-do-i-optimize-this-setup-for-a-low-power-server) for other possible optimizations for a low-power server.
An easy and free SMTP service to set up is [Sendgrid](https://sendgrid.com/). Its free tier allows for up to 100 emails per day to be sent.
## Installing
To set it up, add the following configuration to your `vars.yml` file (adapt to your needs):
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
```yaml
exim_relay_sender_address:"example@example.org"
exim_relay_relay_use:true
exim_relay_relay_host_name:"smtp.sendgrid.net"
exim_relay_relay_host_port:587
exim_relay_relay_auth:true
# This needs to be literally the string "apikey". It is always the same for Sendgrid.
exim_relay_relay_auth_username:"apikey"
# You can generate the API key password at this URL: https://app.sendgrid.com/settings/api_keys
# The password looks something like `SG.955oW1mLSfwds7i9Yd6IA5Q.q8GTaB8q9kGDzasegdG6u95fQ-6zkdwrPP8bOeuI`.
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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 you're having trouble with email not being delivered, it may be useful to inspect the mailer logs.
To do so, log in to the server with SSH and run `journalctl -f -u matrix-exim-relay`.
See [this section](https://github.com/mother-of-all-self-hosting/ansible-role-exim-relay/blob/main/docs/configuring-exim-relay.md#troubleshooting) on the role's documentation for details.
**Note**: this component has been deprecated. We recommend not bothering with installing it. While not a 1:1 replacement, the author suggests taking a look at [Postmoogle](https://github.com/etkecc/postmoogle) as a replacement, which can also be installed using [this playbook](configuring-playbook-bridge-postmoogle.md). Consider using that component instead of this one.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
The playbook can install and configure [Email2Matrix](https://github.com/devture/email2matrix) for you.
# Setting up Email2Matrix (optional, removed)
See the project's [documentation](https://github.com/devture/email2matrix/blob/master/docs/README.md) to learn what it does and why it might be useful to you.
🪦 The playbook used to be able to install and configure [Email2Matrix](https://github.com/devture/email2matrix), but no longer includes this component.
## Preparation
For a long time now, it been replaced by the much better and more maintained [Postmoogle](https://github.com/etkecc/postmoogle) bridge, which can also be [installed using this playbook](configuring-playbook-bridge-postmoogle.md).
### Port availability
Ensure that port 25 is available on your Matrix server and open in your firewall.
## Uninstalling Email2Matrix manually
If you have `postfix` or some other email server software installed, you may need to manually remove it first (unless you need it, of course).
If you really need to run an email server on the Matrix machine for other purposes, it may be possible to run Email2Matrix on another port (with a configuration like `matrix_email2matrix_smtp_host_bind_port: "127.0.0.01:2525"`) and have your other email server relay messages there.
For details about using Email2Matrix alongside [Postfix](http://www.postfix.org/), see [here](https://github.com/devture/email2matrix/blob/master/docs/setup_with_postfix.md).
### Register a dedicated Matrix user (optional, recommended)
We recommend that you create a dedicated Matrix user for Email2Matrix.
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):
If you still have the Email2Matrix 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:
Take note of the user's ID as it needs to be specified as `MatrixUserId` on your `inventory/host_vars/matrix.example.com/vars.yml` file later.
### Obtain an access token
Email2Matrix requires an access token for the sender user to be able to send messages to the room. 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.
### Join to rooms as the sender user manually
ℹ️**Email2Matrix does not accept room invitations automatically**. To deliver messages to rooms, the sender user must be joined to all rooms manually.
For each new room you would like the user to deliver messages to, invite the user to the room.
Then, log in as the sender user using any Matrix client of your choosing, accept the room invitation from the user's account.
Make sure that you and the sender user are part of the same room and that the sender user has enough privileges in the room to be able to send messages there, then log out.
Take note of each room's room ID (different clients show the room ID in a different place). You'll need the room ID when [configuring the playbook](#adjusting-the-playbook-configuration) below.
## Adjusting DNS records
To increase the chances that incoming emails reach your server, you can set up a `MX` record for `matrix.example.com` that looks like this:
| Type | Host | Priority | Weight | Port | Target |
To enable Email2Matrix, add the following configuration to your `vars.yml` file. Make sure to replace `ACCESS_TOKEN_FOR_EMAIL2MATRIX1_HERE` and `ACCESS_TOKEN_FOR_EMAIL2MATRIX2_HERE` with the ones created [above](#obtain-an-access-token).
* MailboxName — local-part of the email address, through which emails are bridged to the room whose ID is defined with MatrixRoomId
* MatrixRoomId — internal ID of the room, to which received emails are sent as Matrix message
* MatrixHomeserverUrl — URL of your Matrix homeserver, through which to send Matrix messages. You can also set `MatrixHomeserverUrl` to the container URL where your homeserver's Client-Server API lives by using the `{{ matrix_addons_homeserver_client_api_url }}` variable
* MatrixUserId — the full ID of the sender user which sends bridged messages to the room. On this configuration it is `@email2matrix1:example.com` and `@email2matrix2:example.com` (where `example.com` is your base domain, not the `matrix.` domain)
* MatrixAccessToken — sender user's access token
* IgnoreSubject — if set to "true", the subject is not bridged to Matrix
* IgnoreBody — if set to "true", the message body is not bridged to Matrix
* SkipMarkdown — if set to "true", emails are bridged as plain text Matrix message instead of Markdown (actually HTML)
Refer to the official documentation [here](https://github.com/devture/email2matrix/blob/master/docs/configuration.md).
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-email2matrix/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. -->
- The shortcut commands with the [`just` program](just.md) are also available: `just install-service email2matrix` or `just setup-all`
`just install-service email2matrix` is useful for maintaining your setup quickly 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 `just setup-all` runs the `ensure-matrix-users-created` tag too.
- After installation, you may wish to send a test email to the email address assigned to `mailbox1` (default: `mailbox1@matrix.example.com`) to make sure that Email2Matrix works as expected.
## 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-email2matrix`.
### Increase logging verbosity
If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
The playbook can install and configure [Etherpad](https://etherpad.org) for you.
Etherpad is an open source collaborative text editor. 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.
When enabled together with the Jitsi audio/videoconferencing system (see [our docs on Jitsi](configuring-playbook-jitsi.md)), it will be made available as an option during the conferences.
When enabled together with the Jitsi video-conferencing platform (see [our docs on Jitsi](configuring-playbook-jitsi.md)), it will be made available as an option during the conferences.
The [Ansible role for Etherpad](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad) is developed and maintained by [the MASH (mother-of-all-self-hosting) project](https://github.com/mother-of-all-self-hosting). For details about configuring Etherpad, you can check them via:
- 🌐 [the role's documentation at the MASH project](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/blob/main/docs/configuring-etherpad.md) online
- 📁 `roles/galaxy/etherpad/docs/configuring-etherpad.md` locally, if you have [fetched the Ansible roles](installing.md#update-ansible-roles)
## Adjusting DNS records
@ -17,13 +34,33 @@ When setting, replace `example.com` with your own.
To enable Etherpad, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
As the most of the necessary settings for the role have been taken care of by the playbook, you can enable Etherpad on your Matrix server with this minimum configuration.
See the role's documentation for details about configuring Etherpad per your preference (such as [the name of the instance](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/blob/main/docs/configuring-etherpad.md#set-the-name-of-the-instance-optional) and [the default pad text](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/blob/main/docs/configuring-etherpad.md#set-the-default-text-optional)).
### Create admin user (optional)
You probably might want to enable authentication to disallow anonymous access to your Etherpad.
It is possible to enable HTTP basic authentication by **creating an admin user** with `etherpad_admin_username` and `etherpad_admin_password` variables. The admin user account is also used by plugins for authentication and authorization.
See [this section](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/blob/main/docs/configuring-etherpad.md#create-admin-user-optional) on the role's documentation for details about how to create the admin user.
### Adjusting the Etherpad URL (optional)
By tweaking the `etherpad_hostname` and `etherpad_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
@ -43,62 +80,26 @@ After changing the domain, **you may need to adjust your DNS** records to point
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
### Configure the default text (optional)
You can also edit the default text on a new pad with the variable `etherpad_default_pad_text`.
To do so, add the following configuration to your `vars.yml` file (adapt to your needs):
```yaml
# Note: the whole text (all of its belonging lines) under the variable needs to be indented with 2 spaces.
etherpad_default_pad_text:|
Welcome to Etherpad!
This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!
Get involved with Etherpad at https://etherpad.org
```
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
- [etherpad role](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad)'s [`defaults/main.yml`](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/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 `etherpad_configuration_extension_json` variable
## 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. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- The `ensure-matrix-users-created` playbook tag makes the playbook automatically create the Etherpad admin user (`etherpad_admin_username`).
- 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.
- If you change the Etherpad admin user's password (`etherpad_admin_password` in your `vars.yml` file) subsequently, the admin user's credentials on the homeserver won't be updated automatically. If you'd like to change the admin user's password, use a tool like [synapse-admin](configuring-playbook-synapse-admin.md) to change it, and then update `etherpad_admin_password` to let the admin user know its new password.
`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
The Etherpad UI should be available at `https://etherpad.example.com`, while the admin UI (if enabled) should then be available at `https://etherpad.example.com/admin`.
By default, the Etherpad UI should be available at `https://etherpad.example.com`, while the admin UI (if enabled) should then be available at `https://etherpad.example.com/admin`.
If you've [decided on another hostname or path-prefix](#adjusting-the-etherpad-url-optional) (e.g. `https://matrix.example.com/etherpad`), adjust these URLs accordingly before using it.
### Managing / Deleting old pads
If you want to manage and remove old unused pads from Etherpad, you will first need to create the Etherpad admin user as described above.
After logging in to the admin web UI, go to the plugin manager page, and install the `adminpads2` plugin.
Once the plugin is installed, you should have a "Manage pads" section in the UI.
💡 For more information about usage, take a look at [this section](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/blob/main/docs/configuring-etherpad.md#usage) on the role's documentation.
### Integrating a Etherpad widget in a room
@ -108,16 +109,4 @@ To integrate a standalone Etherpad in a room, create your pad by visiting `https
## 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-etherpad`.
### 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: ERROR, WARN, INFO, DEBUG
etherpad_configuration_extension_json:|
{
"loglevel": "DEBUG",
}
```
See [this section](https://github.com/mother-of-all-self-hosting/ansible-role-etherpad/blob/main/docs/configuring-etherpad.md#troubleshooting) on the role's documentation for details.
By default, this playbook would set up a PostgreSQL database server on your machine, running in a Docker container. If that's okay, you can skip this document.
By default, your server federates with the whole Matrix network. That is, people on your server can communicate with people on any other Matrix server.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.