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>
As the document for Hookshot has the section for instrucion about configuring its metrics, this commit moves the instruction to it.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The metrics of Synapse belongs to the category of individual services not introduced on the document.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The component has been deprecated and it is not really sensible to keep those entries.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
As prometheus_postgres_exporter_container_labels_traefik_enabled is explained below, it is sensible to remove this duplicated entry in favor of it.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Fix punctuations
- Set the common expression for matrix_authentication_service_config_email_mode
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Now that the warning message is styled with the fancy decoration, it is no longer to wrap them with the hr HTML elements as they are redundant.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Closes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/4039
Partially reverts 30dad8ba27 which renamed
`config.yml` to `config.yaml` in the playbook and on the server, for
consistency with the rest of the playbook.
The problem is that:
- baibot defaults to looking for `config.yml`, not `config.yaml` (as provided).
This can be worked around by specifying a new `BAIBOT_CONFIG_FILE_PATH=config.yaml`
environment variable. This brings more complexity.
- renaming the target file (on the server) to `config.yaml` means people
with an existing installation would drag around the old file (`config.yml`) as well,
unless we create a new Ansible task (`ansible.builtin.file` with `state: absent`) to remove
the old file. This brings more complexity as well.
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/4039 adjusts where the file is mounted,
which fixes the immediate problem (baibot not starting), but still means
people will end up with 2 config files for baibot (`config.yml` and `config.yaml`).
This patch, reverts a bit more, so that we still continue to use `config.yml` on the server.
People who have upgraded within the last ~17 hours may end up with 2 files, but it shouldn't be too many of them.
This commit adopts the common format which can be seen for BorgBackup. It should be probably helpful, though I am not quite sure how much.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
It should be either NGINX or nginx, and this commit converts the string in uppercase to lowercase.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
As the theme deserves the dedicated page and we already have it, it seems sensible to move the topic from the general FAQ page.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
I am not sure what would be the motive to put the instruction for debugging Synapse on maintenance-and-troubleshooting.md above all, but now that we have the common section for an instruction about troubleshooting, it should make sense to move the instruction to the documentation page for configuring Synapse.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Reasoning models like `o1` and `o3` and their `-mini` variants
report errors if we try to configure `max_response_tokens` (which
ultimately influences the `max_tokens` field in the API request):
> invalid_request_error: Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead. (param: max_tokens) (code: unsupported_parameter)
`max_completion_tokens` is not yet supported by baibot, so the best we
can do is at least get rid of `max_response_tokens` (`max_tokens`).
Ref: db9422740c
- Adopt the common introduction
- Remove the ToC
- Merge sections for additional configuration options and extending the configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The section seems to be less relevant than the one for saving metrics on a Prometheus server.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
IMHO it seems to be sensible to concentrate details about maintenance at one documentation page for the sake of maintainability, rather than maintaining pages with a single short section.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Unfortunately Email2Matrix has been deprecated this month. See: f1032f0ac8. As a long time user of the component, I'd like to shout out a big thank-you to Slavi!
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit replaces hyphen characters used as dash with the actual unicode character for dash. It avoids using HTML character entity reference (—), because IMHO it would make it a bit harder to read documents as plain markdown files on your local text editor.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
See roles/custom/matrix-bot-buscarron/defaults/main.yml at 601406ddda for the default log value (INFO).
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Based on docs/configuring-playbook-alertmanager-receiver.md
We can re-sort the levels it if is found out that debug should be placed at the first.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: add the common section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: replace single quotes with backticks
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: adopt the common section "Troubleshooting"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: use the variable specified on main.yml directly
There are other variables specified on .env.j2 such as UVS_ACCESS_TOKEN and UVS_AUTH_TOKEN, but these are not used in the description on the document other than UVS_LOG_LEVEL. This commit therefore replaces the variable with the one specified on main.yml (matrix_user_verification_service_uvs_log_level) to improve consistency.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: fix capitalization
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: replace the placeholder TOKEN with YOUR_TOKEN_HERE
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: change a section title
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>
The comment was copied from roles/custom/matrix-pantalaimon/defaults/main.yml. The latest status of the variable "matrix_pantalaimon_log_level" can be checked on 55fcaac1f1.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
As we automatically forget rooms on leave in the playbook this option working at all is probably heavily desired.
Timing is copied from upstream example.
Credit goes to Anoa for making me even check this.
Note that there is no other "when" on this file. It is not sensible to keep these exceptions here.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This change clarifies that it is the upstream project, not this project owner, that discourages enabling Pantalaimon for Draupnir. This distinction should make it clear who is responsible for the matter.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Multiple use of the phrase "you know what you are doing" does not increase its effect but rather makes it noisy instead. Since it is warned with capitalized "DO NOT", it is enough.
Also replace the order to check in at the upstream with the recommendation, as it is inconsistent for this project overall to ask users to do so. It is not sensible to make an exception for Draupnir.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
I executed a Search for `⚠️ **Warning**:` and replaced it with
```
> [!WARNING]
>
```
I also capitalised the first letter where missing.
Draupnir Docs have been excluded from this Commit as to not cause a separate PR im working on for the Draupnir docs to have potential merge conflicts and im making said change in that document too.
Also: clarify that it is the admin account that needs to be obtained for Synapse's Admin APIs.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Unlike Mjolnir, the step is no longer required. It is optional and recommended on Draupnir, therefore it should be clarified so.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Now that the bot user for Draupnir is created automatically and you no longer need to register it manually since its 2.0.0 version, it does not seem to be sensible to synchronize descriptions about inviting bots between documents for Draupnir and Mjolnir. It is not friendly to instruct to invite the bot which does not exist just yet, only to let the known error message about the nonexistent user displayed.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
In the context of disabling rate limits on an API its disable that is correct. We arent talking about controlling the discharge rate of a battery we dont want to blow up or harm. We are talking about matrix APIs and disabling the rate limiter on them.
https://github.com/Virkkunen and I have been working on the same feature
simultaneously.
This patch adds my additional independent work on top of his changes.
Notable changes here compared to Virkkunen's original work:
- renaming config-related variables (`matrix_conduwuit_*` ->
`matrix_conduwuit_config_*`). This is consistent with other roles (and
better), but deviates from how the Conduit role was implemented.
- using a full configuration sample from https://conduwuit.puppyirl.gay/configuration.html
instead of using the old Conduit config file template
- introducing configurability for more Conduwuit config settings, to support easy registration, etc.
- removing configuration settings that Conduwuit does not support
anymore (e.g. `max_concurrent_requests`)
- cross-linking docs pages for Conduit and Conduwuit
- a Conduwuit docs page which is much improved compared to the old
Conduit one
- REAMDE updates
* Draupnir 2.0.0
The config getting changes all over the place is because of 2.0 having removed a lot of config options due to the code being removed.
* Update Draupnir Documentation to reflect state as of 2.0.0
* Apply Review Feedback
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Change Room IDs found in code review to not conform to playbook standard.
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Further Integrate Code Review Feedback
* Apply remaining suggestions from code review.
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Apply Configuration Review Feedback
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Add Self Registration and Native Login to Draupnir
* Rework Draupnir Documentation to Remove Pantalaimon
* Set bot.draupnir as default username for the bot in config
* Draupnir 2.0.1
* Integrate Review Feedback on Structure of Docs
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
* Further Restructure Docs and tweak variables in response.
* Only auto-create draupnir user if a password has been set
The Draupnir role supports configuring it with either an access token or with a password.
When a password is not assigned (which means the access token mode is used), the user is to be created manually.
* Add ensure-matrix-users-created tag
Now that the Draupnir user may be auto-created in certain configurations (if a password is assigned), it's useful to have the tag there.
---------
Co-authored-by: Suguru Hirahara <luixxiul@users.noreply.github.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-etherpad.md: add the common section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-etherpad.md: add the option to configure the default pad text
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-etherpad.md: remove the detail about setting the unmaintained Dimension default to the Etherpad instance
We have recommended users to avoid installing Dimension since it was deprecated, so it is no longer sensible to discuss how it could be integrated with Etherpad.
This commit also removes the known issue section as it describes the issue which can be experienced on Dimension only.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-etherpad.md: minor changes
- Update the internal anchor link (follow-up to 04b32af0c1)
- minor edits
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Apply the feedback
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>
* Update docs/configuring-playbook-turn.md: add a section for description about installing
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-turn.md and a related file
- Edit the introducion based on docs/configuring-playbook-client-element-web.md
- Adopt the commont format by creating the section "Adjusting the playbook configuration"
- Add the section "Extending the configuration"
- Move the section "Disabling Coturn" to the bottom
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Fix capitalization: Coturn → coturn
See: https://github.com/coturn/coturn. Note that "coturn" is not capitalized even on the start of a sentence, except some rare cases like on the releases page: https://github.com/coturn/coturn/releases
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>
* Update docs/configuring-playbook-backup-borg.md: add the section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-backup-borg.md
- Move the instruction about setting up the server to the section "Prerequisites"
- Replace instructions with a listing with a common format
- Adopt the common descripton for setting a strong password
- Create sections for optional configurations
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-backup-borg.md: add descriptions about other useful options
This commit adds descriptions about options for setting the archive name and the retention policy.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-backup-borg.md: remove the instruction about creating a backup without encryption
It is generally not recommended to store unencrypted backups on computers which you do not own, so this commit removes it from the guide.
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>
Now that the large table for DNS settings is gone, it is sensible to move the section about DNS setting for server delegation down, below the section for DNS configuration for default services.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for DNS settings of the services which need its CNAME record by default
- Buscarron
- Go-NEB; fix a line on the instruction as well
- wsproxy
- Cinny
- Element Web
- Hydrogen
- SchildiChat Web
- Dimension
- Etherpad
- Jitsi
- ntfy
- Grafana
- rageshake
- Sygnal
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for DNS settings of the services which do not need its CNAME record by default
- matrix-alertmanager-receiver
- Honoroit
- maubot
- Heisenbridge
- Cactus Comments
- Matrix Authentication Service
- matrix-registration
- Sliding Sync proxy
- Synapse Admin
- synapse-usage-exporter
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for DNS settings: ma1sd
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for DNS settings: Email2Matrix
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for DNS settings: Postmoogle
Remove the table from configuring-dns.md altogether
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Cinny and Dimension: adopt the common note
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: add "Note" to the line on using Cloudflare DNS
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>
* Update docs/configuring-playbook-jitsi.md: tidy up the introduction
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: minor changes
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: remove the obsolete notice about Element mobile apps not supporting self-hosted Jitsi server
The notice has been obsolete since 993fd04353 (for Android) and 0142bb04e4 (for iOS)
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: create a list for descriptions about each tweak for tuning Jitsi
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: tidy up the section for setting up additional JVBs
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: move down the section for tuning Jitsi
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: include sections to "Adjusting the playbook configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: move the section for confugiring additional JVBs into the 'Usage' section
Since the additional JVBs are supposed to be configured after installing Jitsi with a JVB and it is confusing to place the instruction for configuring them (ansible-playbook -i inventory/hosts --limit jitsi_jvb_servers jitsi_jvb.yml --tags=common,setup-additional-jitsi-jvb,start) above the command for installation (ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start), this commit moves the section for configuring the additional JVBs into the "Usage" section.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: tidy up the section for authentication
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: move the note to the section "Troubleshooting"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: tidy up the section for setting up a Gravatar service
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: replace the description about running behind NAT or on a LAN environment with the official one
Our original description was unorganized and difficult to understand, so this commit simply replaces it with the official documentation provided by Jitsi, which is clear and straightforward.
See: 630a6817c2/docs/devops-guide/docker.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: tidy up the section for rebuilding the Jitsi installation
It feels like the section is no longer relevant pretty much, as one of the main reasons why rebuilding the installation has seemed to be a difficult but reasonable option would be the quality of our documentation; it has been unorganized and it has been difficult to see what needs to be done in which order. Now that the issue was mostly addressed, perhaps it might make sense to remove the section altogether or move it to FAQ.md and rewrite it for components which are as complex as Jitsi.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: switch the order of instructions about adjusting DNS records and adjusting the URL
Since adjusting DNS records does not belong to adjusting the playbook configuration, the section was moved out of it.
This is a first trial of placing the instruction about adjusting DNS records above the section for adjusting the URL. Once it is confirmed that this change makes sense, the other instances will be addressed with another commit.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: switch lines for fine tuning Jitsi to remove a blank line
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: add a practical example of configurations
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: remove a duplicated comment inside jitsi_web_custom_config_extension
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: edit the introduction
Based on docs/configuring-playbook-etherpad.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: remove a mention about the unmaintained Dimension integration manager
As Dimension has been officially declared to be unmaintained and we have stopped recommending to install it since 4574ebbd31, it is a reasonable choice to remove the explanation which suggests to add a Jitsi widget with the component.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: replace the obsolete details about LastN
The document has been removed with 9a955ef1b4.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: minor changes
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: move the description about meetings with authentication enabled out of the section for the default authentication method
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: edit descriptions about authentication methods
Based on f6fdb30997/defaults/main.yml
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: add an anchor link to the Jitsi docs on `matrix` authentication
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>
* Update docs for Dendrite and Synapse: adopt the common section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-synapse.md: move down the section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Dendrite and Synapse: remove redundant descriptions
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-conduit.md: add the common section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Conduit and Dendrite: replace "Notes" with "Warnings" plus the warning symbol
The information is important and should deserve clear attention.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-synapse.md: reorganize sections for adjusting the playbook configuration
As the section for Synapse Admin is not related to adjusting the configuration, it was moved out of the it
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-synapse.md: on Synapse Admin
Based on docs/configuring-playbook-bot-draupnir.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update URLs of the forked Dendrite repository
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Conduit and Dendrite: use the common descriptions for introductions
- Edit the instruction for adjusting the configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-synapse-admin.md: update the URL of the Dendrite documentation
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-synapse.md: add the sections "Installing" and "Usage"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-conduit.md: copy an instruction from roles/custom/matrix-conduit/defaults/main.yml
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Conduit and Dendrite: fix capitalization
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>
* Update docs for Element Web and SchildiChat Web: add the common section "Extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Element Web and SchildiChat Web: remove redundant descriptions
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Element Web and SchildiChat Web: reorganization
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Element Web and SchildiChat Web: edit descriptions about themes
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Element Web and SchildiChat Web: add examples of extending the configuration
This follows docs/configuring-playbook-appservice-draupnir-for-all.md, etc.
Note the examples are available on the main.yml files.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-client-element-web.md: add an instruction about the section on disabling Element Web
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>
* Update docs/configuring-playbook-bridge-mautrix-telegram.md
- Add a link to the official documentation on authentication
- Create subsections in the section "Usage"
- Update the usage based on d33701428d/bridges/python/telegram/authentication.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-twitter.md
- Remove a duplicated "optional" label
- Replace the instruction with a link to the official documentation on authentication
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-appservice-kakaotalk.md
- Adopt a common introduction
- Move the warning message down
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-discord.md
As our instruction on usage has been outdated compared to the latest one (cf. d33701428d/bridges/go/discord/authentication.md), let alone confusing in the first place as our instruction on logging in and bridging have been mixed, this commit updates our instruction based on the latest official one.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-gmessages.md: add a link to the official documentation on authentication
Based on d33701428d/bridges/go/gmessages/authentication.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix-meta bridges: add links to the official documentation on authentication
Based on d33701428d/bridges/go/meta/authentication.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-signal.md: add a link to the official documentation on authentication
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-slack.md
Based on d33701428d/bridges/go/slack/authentication.md
The instruction has been obsolete since 25b4006035
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-googlechat.md
Based on d33701428d/bridges/python/googlechat/authentication.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add information about troubleshooting
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: add descriptions for each mautrix bridge about the bridges behavior after logging in
Based on d33701428d
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: add instruction for sending "help" to the bot to the common guide
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-hangouts.md: adopt a common description about usage
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-whatsapp.md
- Update the note about linked devices that they will be logged out if the phone is not used over two weeks: the note has been obsolete since 0860109d05
- Adopt a common description about usage
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: fix the internal anchor link
Regression by 4b2e066a61
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add a note about the official docs
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-go-skype-bridge.md: adopt the common description
As the bridge was created based on mautrix-whatsapp, this commit adopts the common descriptions for mautrix bridges and ones based on them such as matrix-appservice-kakaotalk and beeper-linkedin
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>
* Update docs for mautrix bridges: common section for extending the configuration
Add links to the common guide for configuring mautrix bridges
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: add the sections 'extending the configuration'
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: add the common section "extending the configuration" based on docs for mautrix bridges
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: edit the top section
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: common section for setting up Double Puppeting
Based on docs/configuring-playbook-bridge-mautrix-meta-instagram.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: common section for setting up Double Puppetting
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: replace duplicated descriptions for setting up Double Puppeting with a link to docs/configuring-playbook-bridge-mautrix-bridges.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: remove the section for setting up Double Puppeting
The instruction has been described already in the section for prerequisites
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: add sections for enabling double puppeting
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: adopt common descriptions about bridge permissions
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-whatsapp.md: remove description for relay-bot
For WhatsApp the default relay mode is used and the description for it is available on the common guide for configuring mautrix bridges.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: remove descriptions about permissions in favor of the common one on docs/configuring-playbook-bridge-mautrix-bridges.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: remove a redundant instruction for referring to the section for troubleshooting
The section is just below the instruction.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: add notes about double puppeting with the Shared Secret Auth
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: remove redundant descriptions
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: remove links to the description about the relay mode from configuring-playbook-bridge-mautrix-bridges.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-telegram.md: move the section for instruction about using the bridge for direct chat only
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add configuration for relay to an example of matrix_mautrix_SERVICENAME_configuration_extension_yaml
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: add a header for the reference to the common guide
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: adopt the common description for the section "Usage"
Fix docs/configuring-playbook-bridge-mautrix-bridges.md: simplify the instruction to refer each documentation page (note that there are two formats of the links: https://docs.mau.fi/bridges/python/SERVICENAME/authentication.html and https://docs.mau.fi/bridges/go/SERVICENAME/authentication.html)
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix bridges: edit anchor links to official documentation pages
- Add links to the official documentation pages
- Remove links to Hangouts' documentation page: the links have been replaced with ones to Google Chat bridge and the resources about Hangouts bridge have been removed
- Replace links to documentation pages in python version with ones in go version
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: add a note about variable names
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: re-add the section for instruction about appservice double puppeting
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>
* Update docs/configuring-playbook-mautrix-bridges.md: edit the section "extending the configuration"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-mautrix-bridges.md: edit section headers
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-mautrix-bridges.md: edit the section "Control the logging level"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-mautrix-bridges.md: replace examples for service name
- Remove hangout, which has been shut down and whose role is soon to be removed from the playbook
- Add a note about the Mautrix Meta bridge
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-mautrix-bridges.md: add descriptions to each section
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-mautrix-bridges.md: move the section "Set up Double Puppeting" to "Usage"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename docs/configuring-playbook-mautrix-bridges.md to docs/configuring-playbook-bridge-mautrix-bridges.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: edit an instruction
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add the manual step for setting up Double Puppetting
Based on other documents for mautrix bridges like docs/configuring-playbook-bridge-mautrix-discord.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add a note about bridges' incompatibility with Appservice Double Puppet
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: adopt the description on docs/configuring-playbook-appservice-double-puppet.md
Make it clear that Double Puppetting with the other methods than the appservice one has been superseded. See: https://docs.mau.fi/bridges/general/double-puppeting.html#automatically
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add "recommended" label to the first method of setting up Double Puppeting
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add anchor links to the official documentation
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add descriptions about configuring bridge permissions
Partially based on docs/configuring-playbook-bridge-mautrix-meta-instagram.md etc.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: add description about the relaybot
Based on:
- the official documentation: https://docs.mau.fi/bridges/general/relay-mode.html
- docs/configuring-playbook-bridge-mautrix-whatsapp.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: remove a duplicated anchor link
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook.md: add an anchor link to configuring-playbook-bridge-mautrix-bridges.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: edit a sentence
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-bridges.md: reflect the review
See https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3913#discussion_r1903215741
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
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>
* Add a warning sign to "Warning" labels
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-matrix-registration.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/maintenance-and-troubleshooting.md: remove a section for ma1sd
As the project has not updated since several years, it does not seem to be reasonable to pick it up specially on the document.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Common header for sections about adjusting the playbook configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-dendrite.md: fix links to dendrite.yaml.j2
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-signal.md: remove a note added by a commit to remove signalgo
The note has been added with 2f6525ccb3, apparently copied from docs/configuring-playbook-bridge-mautrix-signalgo.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-wsproxy.md: fix the anchor link text to mautrix-imessage documentation
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-etherpad.md: add a note about the component being managed externally
Refer docs/configuring-playbook-backup-borg.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: use the common label for warning messages
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ldap-auth.md: unrecommend using ma1sd for authentication
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-double-puppet.md: remove a duplicate anchor link
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for old mautrix bridges for Facebook and Instagram: remove anchor links to the deleted files
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-wechat.md: use common descriptions
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-matrix-bridge-sms.md: create a section for the prerequisite
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/maintenance-and-troubleshooting.md: use the common header text
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Use common descriptions for adding the configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-mautrix-telegram.md: small edits
- Add a section for a Telegram API key
- Add a section for instruction about Appservice Double Puppet or Shared Secret Auth
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for Draupnir and Mjolnir: replace colons with periods
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-rageshake.md: adopt the common instruction
Based on docs/configuring-playbook-sygnal.md regarding the notification about necessity of the service.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add a note about the components managed externally
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>
* Update docs/configuring-playbook-user-verification-service.md: adopt the common section for controlling the logging level
Based on:
- docs/configuring-playbook-bridge-mautrix-bridges.md
- roles/custom/matrix-user-verification-service/defaults/main.yml
Other minor changes:
- Add an upper section "troubleshooting" for "TLS Certificate Checking"
- Use backticks
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md
---------
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>
* Update docs/configuring-playbook-user-verification-service.md: add the common introduction
Based on docs/configuring-playbook-dimension.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: use a common placeholder for an access token
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: use a common header for adjusting the playbook configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: instruction for registering a dedicated user
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: use abbreviation
See the line 3.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: move the section for obtaining an access token up
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: remove a redundant paragraph about necessity of token
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs: notes on port 8448 for federation, etc.
- Create sections for the instruction about opening Matrix Federation port
- Remove unmaintained components which this project does not recommend to install from examples about opening the port on docs/prerequisites.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: create a section for explaining the function of the component
Based on docs/configuring-playbook-prometheus-grafana.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: add a note about creating user as an admin
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-user-verification-service.md: merge the section "Configuration" and edit it
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
---------
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>
* Add logout_redirect_url var and option templating for matrix element client
* Simplify logout_redirect_url templating and make it safer
Using `to_json` to make it safer.
Judging by the code here 0b24d33c64/src/Lifecycle.ts (L1026-L1032)
it doesn't seem like it leaving `logout_redirect_url` empty will hurt, so this patch removes the `if` block.
* Add comment for the `matrix_client_element_logout_redirect_url` variable
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Based on docs/configuring-playbook-dimension.md and docs/configuring-playbook-bot-go-neb.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Register a dedicated Matrix user (optional)
- Obtain an access token
Since Dimension has been archived, this is purely for possible use as a template of another component.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
2024-12-24 01:52:32 +09:00
1494 changed files with 47150 additions and 28746 deletions
A clear and concise description of what the bug is.
<!--
NOTE: This Ansible playbook installs tens of separate services. If you're having a problem with a specific service, it is likely that the problem is not with our deployment method, but with the service itself. You may wish to report that problem at the source, upstream, and not to us
NOTE: This Ansible playbook installs tens of separate services. If you're having a problem with a specific one, it is likely that the problem is with the service itself. You may wish to report that problem at the source, upstream.
-->
**To Reproduce**
@ -34,7 +34,7 @@ A clear and concise description of what you expected to happen.
**Ansible:**
If your problem appears to be with Ansible, tell us:
- where you run Ansible -- e.g. on the Matrix server itself; on another computer (which OS? distro? standard installation or containerized Ansible?)
- where you run Ansible — e.g. on the Matrix server itself; on another computer (which OS? distro? standard installation or containerized Ansible?)
- what version of Ansible you're running (see `ansible --version`)
@ -13,7 +13,9 @@ A clear and concise description of what the problem is. Ex. I'm always frustrate
<!--
NOTE: When submitting feature requests, be aware that:
-This Ansible playbook installs tens of separate services. If you're having a problem with a specific service or you'd like some functionality added to it, it is likely that the problem is not with our deployment method, but with the service itself. You may wish to report that problem at the source, upstream, and not to us.
-This Ansible playbook installs tens of separate services. If you're having a problem with a specific one, it is likely that the problem is with the service itself. You may wish to report that problem at the source, upstream.
-This playbook intends to focus solely on Matrix and Matrix-related services. If your request is not specific to them, you may as well to consider to submit it to the mash-playbook project: https://github.com/mother-of-all-self-hosting/mash-playbook
-This is a community project with no financial backing. The easiest way to get a feature into this project is to just develop it yourself.
[](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
@ -52,7 +52,9 @@ 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) |
| [Dendrite](https://github.com/matrix-org/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) |
| [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
@ -64,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
@ -72,12 +75,14 @@ Services that run on the server to make the various parts of your installation w
| Name | Default? | Description | Documentation |
| ---- | -------- | ----------- | ------------- |
| [PostgreSQL](https://www.postgresql.org/)| ✅ | Database for Synapse. [Using an external PostgreSQL server](docs/configuring-playbook-external-postgres.md) is also possible. | [Link](docs/configuring-playbook-external-postgres.md) |
| [Coturn](https://github.com/coturn/coturn) | ✅ | STUN/TURN server for WebRTC audio/video calls | [Link](docs/configuring-playbook-turn.md) |
| [Traefik](https://doc.traefik.io/traefik/) | ✅ | Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. Using your own webserver [is possible](docs/configuring-playbook-own-webserver.md) | [Link](docs/configuring-playbook-traefik.md) |
| [coturn](https://github.com/coturn/coturn) | ✅ | STUN/TURN server for WebRTC audio/video calls | [Link](docs/configuring-playbook-turn.md) |
| [Traefik](https://doc.traefik.io/traefik/) | ✅ | Web server, listening on ports 80, 443 and 8448 - standing in front of all the other services. [Using your own webserver](docs/configuring-playbook-own-webserver.md) is also possible. | [Link](docs/configuring-playbook-traefik.md) |
| [Let's Encrypt](https://letsencrypt.org/) | ✅ | Free SSL certificate, which secures the connection to all components | [Link](docs/configuring-playbook-ssl-certificates.md) |
| [Exim](https://www.exim.org/) | ✅ | Mail server, through which all Matrix services send outgoing email (can be configured to relay through another SMTP server) | [Link](docs/configuring-playbook-email.md) |
| [ma1sd](https://github.com/ma1uta/ma1sd) | ❌ | Matrix Identity Server | [Link](docs/configuring-playbook-ma1sd.md)
| [ddclient](https://github.com/linuxserver/docker-ddclient) | ❌ | Dynamic DNS | [Link](docs/configuring-playbook-dynamic-dns.md) |
| [LiveKit Server](https://github.com/livekit/livekit) | ❌ | WebRTC server for audio/video calls | [Link](docs/configuring-playbook-livekit-server.md) |
| [Livekit JWT Service](https://github.com/livekit/livekit-jwt-service) | ❌ | JWT service for integrating [Element Call](./configuring-playbook-element-call.md) with [LiveKit Server](./configuring-playbook-livekit-server.md) | [Link](docs/configuring-playbook-livekit-jwt-service.md) |
### Authentication
@ -88,10 +93,10 @@ Extend and modify how users are authenticated on your homeserver.
| [matrix-ldap-registration-proxy](https://gitlab.com/activism.international/matrix_ldap_registration_proxy) (advanced) | ❌ | A 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) | ❌ | A 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-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) | ❌ | Service to verify details of a user based on an Open ID token | [Link](docs/configuring-playbook-user-verification-service.md) |
| [matrix-media-repo](https://github.com/turt2live/matrix-media-repo) | ❌ | matrix-media-repo is a highly customizable multi-domain media repository for Matrix. Intended for medium to large deployments, this media repo de-duplicates media while being fully compliant with the specification. | [Link](docs/configuring-playbook-matrix-media-repo.md) |
| [matrix-media-repo](https://github.com/turt2live/matrix-media-repo) | ❌ | Highly customizable multi-domain media repository for Matrix. Intended for medium to large deployments, this media repo de-duplicates media while being fully compliant with the specification. | [Link](docs/configuring-playbook-matrix-media-repo.md) |
### Bridges
@ -115,6 +120,7 @@ Bridges can be used to connect your Matrix installation with third-party communi
| [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) |
@ -135,7 +141,6 @@ Bridges can be used to connect your Matrix installation with third-party communi
@ -144,13 +149,13 @@ Bots provide various additional functionality to your installation.
| Name | Default? | Description | Documentation |
| ---- | -------- | ----------- | ------------- |
| [baibot](https://github.com/etkecc/baibot) | ❌ | A bot that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you | [Link](docs/configuring-playbook-bot-baibot.md) |
| [baibot](https://github.com/etkecc/baibot) | ❌ | Bot that exposes the power of [AI](https://en.wikipedia.org/wiki/Artificial_intelligence) / [Large Language Models](https://en.wikipedia.org/wiki/Large_language_model) to you | [Link](docs/configuring-playbook-bot-baibot.md) |
| [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) | ❌ | Bot for scheduling one-off & recurring reminders and alarms | [Link](docs/configuring-playbook-bot-matrix-reminder-bot.md) |
| [matrix-registration-bot](https://github.com/moan0s/matrix-registration-bot) | ❌ | Bot for invitations by creating and managing registration tokens | [Link](docs/configuring-playbook-bot-matrix-registration-bot.md) |
| [maubot](https://github.com/maubot/maubot) | ❌ | A plugin-based Matrix bot system | [Link](docs/configuring-playbook-bot-maubot.md) |
| [Matrix Authentication Service](https://github.com/element-hq/matrix-authentication-service/) | ❌ | OAuth 2.0 and OpenID Provider server | [Link](docs/configuring-playbook-matrix-authentication-service.md) |
| [synapse-admin](https://github.com/etkecc/synapse-admin) | ❌ | A web UI tool for administrating users and rooms on your Matrix server | [Link](docs/configuring-playbook-synapse-admin.md) |
| Metrics and Graphs | ❌ | Consists of the [Prometheus](https://prometheus.io) time-series database server, the Prometheus [node-exporter](https://prometheus.io/docs/guides/node-exporter/) host metrics exporter, and the [Grafana](https://grafana.com/) web UI, with [prometheus-nginxlog-exporter](https://github.com/martin-helmich/prometheus-nginxlog-exporter/) being available too | [Link](docs/configuring-playbook-prometheus-grafana.md) (for [prometheus-nginxlog-exporter](docs/configuring-playbook-prometheus-nginxlog.md)) |
| [synapse-admin](https://github.com/etkecc/synapse-admin) | ❌ | Web UI tool for administrating users and rooms on your Matrix server | [Link](docs/configuring-playbook-synapse-admin.md) |
| Metrics and Graphs | ❌ | Consists of the [Prometheus](https://prometheus.io) time-series database server, the Prometheus [node-exporter](https://prometheus.io/docs/guides/node-exporter/) host metrics exporter, and the [Grafana](https://grafana.com/) web UI, with [prometheus-nginxlog-exporter](https://github.com/martin-helmich/prometheus-nginxlog-exporter/) being available too | [Link](docs/configuring-playbook-prometheus-grafana.md) (for [prometheus-nginxlog-exporter](docs/configuring-playbook-prometheus-grafana.md#enable-metrics-and-graphs-for-nginx-logs-optional)) |
| [synapse-usage-exporter](https://github.com/loelkes/synapse-usage-exporter) | ❌ | Export the usage statistics of a Synapse homeserver to be scraped by Prometheus. | [Link](docs/configuring-playbook-synapse-usage-exporter.md) |
@ -174,15 +179,16 @@ Various services that don't fit any other categories.
| Name | Default? | Description | Documentation |
| ---- | -------- | ----------- | ------------- |
| [sliding-sync](https://github.com/matrix-org/sliding-sync)| ❌ | (Superseded by Simplified Sliding Sync integrated into Synapse > `1.114` and Conduit > `0.6.0`) Sliding Sync support for clients which require it (e.g. old Element X versions before Simplified Sliding Sync was developed) | [Link](docs/configuring-playbook-sliding-sync-proxy.md) |
| [synapse_auto_accept_invite](https://github.com/matrix-org/synapse-auto-accept-invite) | ❌ | A Synapse module to automatically accept invites. | [Link](docs/configuring-playbook-synapse-auto-accept-invite.md) |
| [synapse_auto_compressor](https://github.com/matrix-org/rust-synapse-compress-state/#automated-tool-synapse_auto_compressor) | ❌ | A cli tool that automatically compresses `state_groups` database table in background. | [Link](docs/configuring-playbook-synapse-auto-compressor.md) |
| [synapse_auto_compressor](https://github.com/matrix-org/rust-synapse-compress-state/#automated-tool-synapse_auto_compressor) | ❌ | Cli tool that automatically compresses `state_groups` database table in background | [Link](docs/configuring-playbook-synapse-auto-compressor.md) |
| [Matrix Corporal](https://github.com/devture/matrix-corporal) (advanced) | ❌ | Reconciliator and gateway for a managed Matrix server | [Link](docs/configuring-playbook-matrix-corporal.md) |
| [Etherpad](https://etherpad.org) | ❌ | An open source collaborative text editor | [Link](docs/configuring-playbook-etherpad.md) |
| [Jitsi](https://jitsi.org/) | ❌ | An open source video-conferencing platform | [Link](docs/configuring-playbook-jitsi.md) |
| [Cactus Comments](https://cactus.chat) | ❌ | A federated comment system built on Matrix | [Link](docs/configuring-playbook-cactus-comments.md) |
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.
@ -52,7 +59,7 @@ Hopefully, Synapse defaults would also change the same way and we'd see the numb
With this configuration change in place, projects like [MatrixRooms.info](https://matrixrooms.info/) (made by [etke.cc](https://etke.cc/)) and potentially others in the future, can discover, index the metadata (room address, title, topic, number of users, etc.) and make public rooms browsable & searchable across the whole Matrix Federation. It'd be great if users joining Matrix could more easily find interesting communities that match their interests!
On the **media side of things**, besides Jitsi getting better Matrix integration (via the aforementioned Matrix User Verification Service), we've also had some [Coturn security tightening](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#backward-compatibility-tightening-coturn-security-can-lead-to-connectivity-issues) as well as [performance optimizations](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#coturn-can-now-use-host-networking) for configurations exposing lots of network ports.
On the **media side of things**, besides Jitsi getting better Matrix integration (via the aforementioned Matrix User Verification Service), we've also had some [coturn security tightening](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#backward-compatibility-tightening-coturn-security-can-lead-to-connectivity-issues) as well as [performance optimizations](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#coturn-can-now-use-host-networking) for configurations exposing lots of network ports.
[Element Call](https://github.com/element-hq/element-call) seems to have become a nice and polished product lately (as proclaimed in [The Matrix Holiday Update 2023](https://matrix.org/blog/2023/12/25/the-matrix-holiday-update-2023/)), so 2024 is likely the year we'll see support for it in the playbook. Element Call depends on the [LiveKit](https://livekit.io/) streaming server (which is also useful to developers even by itself), so the first step is likely to see LiveKit support in mash-playbook via a reusable Ansible role. Such a LiveKit Ansible role could later easily land in matrix-docker-ansible-deploy and an Element Call static website could be hooked to it.
@ -69,7 +76,7 @@ When it comes to the `matrix-docker-ansible-deploy` Ansible playbook, 2022 was t
Support for the following new **bridges** was added:
* [Postmoogle](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#postmoogle-email-bridge-support) for bi-directional email bridging, which supersedes my old and simplistic [email2matrix](https://github.com/devture/email2matrix) one-way bridge-bot
* [Postmoogle](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#postmoogle-email-bridge-support) for bi-directional email bridging, which supersedes my old and simplistic [Email2Matrix](https://github.com/devture/email2matrix) one-way bridge-bot
# 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
## ⬇️ Installaton guides <!-- NOTE: the 🚀 emoji is used by "Getting started" on README.md -->
## ⬇️ Installation guides <!-- NOTE: the 🚀 emoji is used by "Getting started" on README.md -->
There are two installation guides available for beginners and advanced users.
@ -10,7 +19,7 @@ There are two installation guides available for beginners and advanced users.
- [Prerequisites](prerequisites.md)
- [Configuring your DNS settings](configuring-dns.md)
- [Configuring DNS settings](configuring-dns.md)
- [Getting the playbook](getting-the-playbook.md)
@ -27,23 +36,23 @@ NOTE:
You can check useful documentation for configuring components here: [Configuring the playbook](configuring-playbook.md)
- [Administration](configuring-playbook.md#administration) - services that help you in administrating and monitoring your Matrix installation
- [Administration](configuring-playbook.md#administration) — services that help you in administrating and monitoring your Matrix installation
- [Authentication and user-related](configuring-playbook.md#authentication-and-user-related) - extend and modify how users are authenticated on your homeserver
- [Authentication and user-related](configuring-playbook.md#authentication-and-user-related) — extend and modify how users are authenticated on your homeserver
- [Bots](configuring-playbook.md#bots) - bots provide various additional functionality to your installation
- [Bots](configuring-playbook.md#bots) — bots provide various additional functionality to your installation
- [Bridges](configuring-playbook.md#bridging-other-networks) - bridges can be used to connect your Matrix installation with third-party communication networks
- [Bridges](configuring-playbook.md#bridging-other-networks) — bridges can be used to connect your Matrix installation with third-party communication networks
- [Clients](configuring-playbook.md#clients) - web clients for Matrix that you can host on your own domains
- [Clients](configuring-playbook.md#clients) — web clients for Matrix that you can host on your own domains
- [Core service adjustments](configuring-playbook.md#core-service-adjustments) - backbone of your Matrix system
- [Core service adjustments](configuring-playbook.md#core-service-adjustments) — backbone of your Matrix system
- [File Storage](configuring-playbook.md#file-storage) - use alternative file storage to the default `media_store` folder
- [File Storage](configuring-playbook.md#file-storage) — use alternative file storage to the default `media_store` folder
<!-- NOTE: sort list items above alphabetically -->
- [Other specialized services](configuring-playbook.md#other-specialized-services) - various services that don't fit any other categories
- [Other specialized services](configuring-playbook.md#other-specialized-services) — various services that don't fit any other categories
## 👨🔧 Maintenance
@ -51,8 +60,6 @@ If your server and services experience issues, feel free to come to [our support
<!-- NOTE: sort list items alphabetically -->
- [Checking if services work](maintenance-checking-services.md)
- [Maintenance and Troubleshooting](maintenance-and-troubleshooting.md)
This playbook is meant to be run using [Ansible](https://www.ansible.com/).
@ -29,9 +38,12 @@ 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 you're using a very recent Ansible version, which is less likely to be incompatible with the playbook.
This ensures that:
- you're using a very recent Ansible version, which is less likely to be incompatible with the playbook
- you also get access to the [agru](https://github.com/etkecc/agru) tool for quicker Ansible role installation (when running `just roles`) compared to `ansible-galaxy`
You can either [run Ansible in a container on the Matrix server itself](#running-ansible-in-a-container-on-the-matrix-server-itself) or [run Ansible in a container on another computer (not the Matrix server)](#running-ansible-in-a-container-on-another-computer-not-the-matrix-server).
@ -42,54 +54,58 @@ To run Ansible in a (Docker) container on the Matrix server itself, you need to
- you **either** need to install Docker manually first. Follow [the upstream instructions](https://docs.docker.com/engine/install/) for your distribution and consider setting `matrix_playbook_docker_installation_enabled: false` in your `vars.yml` file, to prevent the playbook from installing Docker
- **or** you need to run the playbook in another way (e.g. [Running Ansible in a container on another computer (not the Matrix server)](#running-ansible-in-a-container-on-another-computer-not-the-matrix-server)) at least the first time around
Once you have a working Docker installation on the server, **clone the playbook** somewhere on the server and configure it as per usual (`inventory/hosts`, `inventory/host_vars/..`, etc.), as described in [configuring the playbook](configuring-playbook.md).
Once you have a working Docker installation on the server, **clone the playbook** somewhere on the server and configure it as per usual (`inventory/hosts`, `inventory/host_vars/…`, etc.), as described in [configuring the playbook](configuring-playbook.md).
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-0
ghcr.io/devture/ansible:11.1.0-r0-0
```
Once you execute the above command, you'll be dropped into a `/work` directory inside a Docker container. The `/work` directory contains the playbook's code.
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:
@ -97,11 +113,11 @@ To authenticate at your server using a password, you need to add a package. So,
apk add sshpass
```
Then, to be asked for the password whenever running an `ansible-playbook` command add `--ask-pass` to the arguments of the command.
Then, to be asked for the password whenever running an `ansible-playbook` command add `--ask-pass` to the arguments of the command.
#### 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.
## DNS settings for services enabled by default
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 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.
Be mindful as to how long it will take for the DNS records to propagate.
**Note**: if you are using Cloudflare DNS, make sure to disable the proxy and set all records to "DNS only". Otherwise, fetching certificates will fail.
## DNS setting for server delegation (optional)
In the sample `vars.yml` ([`examples/vars.yml`](../examples/vars.yml)), we recommend to use a short user ID like `@alice:example.com` instead of `@alice:matrix.example.com`.
@ -21,58 +58,6 @@ If you choose the recommended method (file-based delegation), you do not need to
On the other hand, if you choose this method (setting up a DNS SRV record), you need to configure the additional DNS record as well as adjust SSL certificate handling. Take a look at this documentation for more information: [Server Delegation via a DNS SRV record (advanced)](howto-server-delegation.md#server-delegation-via-a-dns-srv-record-advanced)
## DNS settings for services enabled by default
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).
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.
Be mindful as to how long it will take for the DNS records to propagate.
If you are using Cloudflare DNS, make sure to disable the proxy and set all records to "DNS only". Otherwise, fetching certificates will fail.
## DNS settings for optional services/features
For other services which may need subdomain settings, see the table below and configure the DNS (`CNAME`) records accordingly.
| Used by component | Type | Host | Priority | Weight | Port | Target |
| [Postmoogle](configuring-playbook-bridge-postmoogle.md) email bridge | TXT | `postmoogle._domainkey.matrix` | - | - | - | get it from `!pm dkim` |
### SRV record for ma1sd
To make ma1sd enable its federation features, you need to set up a `_matrix-identity._tcp` SRV record. Don't confuse this with the `_matrix._tcp` SRV record for server delegation. See the table above and [this section](configuring-playbook-ma1sd.md#adjusting-dns-records) for values which need to be specified.
When setting up a SRV record, if you are asked for a service and protocol instead of a hostname split the host value from the table where the period is. For example use service as `_matrix-identity` and protocol as `_tcp`.
### MX and TXT records for Postmoogle
To make Postmoogle enable its email sending features, you need to configure MX and TXT (SPF, DMARC, and DKIM) records. See the table above for values which need to be specified.
---------------------------------------------
[▶️](getting-the-playbook.md) When you're done with the DNS configuration and ready to proceed, continue with [Getting the playbook](getting-the-playbook.md).
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.
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
⚠️ **Warning**: Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
> [!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 bot manually
@ -36,6 +45,12 @@ For each new room you would like the bot to deliver alerts to, invite the bot to
Then, log in as the bot using any Matrix client of your choosing, accept the room invitation from the bot's account, and log out.
## Adjusting DNS records (optional)
By default, this playbook installs matrix-alertmanager-receiver on the `matrix.` subdomain, at the `/matrix-alertmanager-receiver` path (https://matrix.example.com/matrix-alertmanager-receiver). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
If you wish to adjust it, see the section [below](#adjusting-the-matrix-alertmanager-receiver-url-optional) for details about DNS configuration.
## Adjusting the playbook configuration
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
See `roles/custom/matrix-alertmanager-receiver/defaults/main.yml` for additional configuration variables.
### Adjusting the matrix-alertmanager-receiver URL
By default, this playbook installs matrix-alertmanager-receiver on the `matrix.` subdomain, at the `/matrix-alertmanager-receiver` path (https://matrix.example.com/matrix-alertmanager-receiver). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
### Adjusting the matrix-alertmanager-receiver URL (optional)
By tweaking the `matrix_alertmanager_receiver_hostname` and `matrix_alertmanager_receiver_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
If you've changed the default hostname, you may need to create a CNAME record for the matrix-alertmanager-receiver domain (`alertmanager.example.com`), which targets `matrix.example.com`.
If you've changed the default hostname, **you may need to adjust your DNS** records to point the matrix-alertmanager-receiver domain to the Matrix server.
When setting, replace `example.com` with your own.
See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
If you've decided to use the default hostname, you won't need to do any extra DNS configuration.
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-alertmanager-receiver/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-alertmanager-receiver/templates/config.yaml.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_alertmanager_receiver_configuration_extension_yaml` variable
## Installing
@ -89,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.
## Usage
@ -122,3 +134,16 @@ route:
```
where `URL_HERE` looks like `https://matrix.example.com/matrix-alertmanager-receiver-RANDOM_VALUE_HERE/alert/some-room-name` or `https://matrix.example.com/matrix-alertmanager-receiver-RANDOM_VALUE_HERE/alert/!qporfwt:example.com`.
## 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-alertmanager-receiver`.
### Increase logging verbosity
The default logging level for this component is `info`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
Appservice Double Puppet is a homeserver appservice through which bridges (and potentially other services) can impersonate any user on the homeserver.
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.
This is useful for performing [double-puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) via the [appservice method](https://docs.mau.fi/bridges/general/double-puppeting.html#appservice-method-new). The Appservice Double Puppet service is an implementation of this approach.
This is useful for performing [double-puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) via the appservice method. The service is an implementation of this approach.
Previously, bridges supported performing [double-puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) with the help of the [Shared Secret Auth password provider module](./configuring-playbook-shared-secret-auth.md), but this old and hacky solution has been superseded by this Appservice Double Puppet method.
Previously, bridges supported performing double-puppeting with the help of the [Shared Secret Auth password provider module](./configuring-playbook-shared-secret-auth.md), but this old and hacky solution has been superseded by this Appservice Double Puppet method.
## Adjusting the playbook configuration
@ -14,23 +21,27 @@ To enable the Appservice Double Puppet service, add the following configuration
matrix_appservice_double_puppet_enabled:true
```
### Extending the configuration
There are some additional things you may wish to configure about the service.
Take a look at:
-`roles/custom/matrix-appservice-double-puppet/defaults/main.yml` for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_appservice_double_puppet_registration_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`
- 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
When enabled, double puppeting will automatically be enabled for all bridges that support double puppeting via the appservice method.
Installing the service will automatically enable double puppeting for all bridges that support double puppeting via the appservice method.
The playbook can install and configure the [Draupnir](https://github.com/the-draupnir-project/Draupnir) moderation tool for you in appservice mode.
@ -24,19 +31,12 @@ The playbook does not create a management room for your Main Draupnir. You **nee
Note that the room must be unencrypted.
<!-- TODO: enable Pantalaimon as configuring-playbook-bot-draupnir.md -->
The management room has to be given an alias and be public when you are setting up the bot for the first time as the bot does not differentiate between invites and invites to the management room.
The management room has to be given an alias, and your bot has to be invited to the room.
This management room is used to control who has access to your D4A deployment. The room stores this data inside of the control room state so your bot must have sufficient powerlevel to send custom state events. This is default 50 or moderator as Element clients call this powerlevel.
As noted in the Draupnir install instructions the control room is sensitive. **Anyone in this room can control the bot so it is important that you only invite trusted users to this room.**
### Set an alias to the management room
Next, set an alias to the management room.
This alias can be anything you want. However, for increased security during the setup phase, it is recommended to make this alias be a random string. When it has been locked down after setup phase, you can give your room a secondary human readable alias.
> [!WARNING]
> Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
## Adjusting the playbook configuration
@ -45,24 +45,28 @@ Add the following configuration to your `inventory/host_vars/matrix.example.com/
You can configure additional options by adding the `matrix_appservice_draupnir_for_all_extension_yaml` variable.
There are some additional things you may wish to configure about the component.
For example, to change Draupnir's `protectAllJoinedRooms` option to `true`, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
Take a look at:
-`roles/custom/matrix-appservice-draupnir-for-all/defaults/main.yml` for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_appservice_draupnir_for_all_configuration_extension_yaml` variable
For example, to change Draupnir's `protectAllJoinedRooms` option to `true`, add the following configuration to your `vars.yml` file:
@ -80,30 +84,28 @@ 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.
## Usage
If you made it through all the steps above and your main control room was joined by a user called `@draupnir-main:example.com` you have 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))
To allow users or whole homeservers you type /plain @draupnir-main:example.com allow `target` and target can be either a MXID or a wildcard like `@*:example.com` to allow all users on example.com to register. We use /plain to force the client to not attempt to mess with this command as it can break Wildcard commands especially.
To allow users or whole homeservers you type /plain !admin allow `target` and target can be either a MXID or a wildcard like `@*:example.com` to allow all users on example.com to register. We use /plain to force the client to not attempt to mess with this command as it can break Wildcard commands especially.
### How to provision a D4A once you are allowed to
The playbook can install and configure [BorgBackup](https://www.borgbackup.org/) (short: Borg) with [borgmatic](https://torsion.org/borgmatic/) for you.
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.
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).
The backup will run based on `backup_borg_schedule` var (systemd timer calendar), default: 4am every day.
By default, 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. 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.
**Note**: the component is not managed by this repository but its [own repository](https://github.com/mother-of-all-self-hosting/ansible-role-backup_borg).
## Prerequisites
1. If you do not disable Postgres-backup support, make sure that the Postgres version of your homeserver's database is compatible with borgmatic.
* REPO - BorgBackup repository name, it will be initialized on backup start, eg: `matrix`, regarding Syntax see [Remote repositories](https://borgbackup.readthedocs.io/en/stable/usage/general.html#repository-urls)
* PASSPHRASE - passphrase used for encrypting backups. You can create one with a command like `pwgen -s 64 1`.
* PRIVATE KEY - the content of the **private** part of the SSH key you created before. The whole key (all of its belonging lines) under `backup_borg_ssh_key_private` needs to be indented with 2 spaces
To backup without encryption, add `backup_borg_encryption: 'none'` to your vars. This will also enable the `backup_borg_unknown_unencrypted_repo_access_is_ok` variable.
`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 want to exclude certain directories or file patterns from the backup using the `backup_borg_location_exclude_patterns` variable.
Check the [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) file for the full list of available options.
## 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.
## Manually start a backup
For testing your setup it can be helpful to not wait until 4am. If you want to run the backup immediately, log onto the server and run `systemctl start matrix-backup-borg`. This will not return until the backup is done, so possibly a long time. Consider using [tmux](https://en.wikipedia.org/wiki/Tmux) if your SSH connection is unstable.
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.
@ -107,7 +114,7 @@ Configuring `matrix_bot_baibot_config_initial_global_config_user_patterns` is op
**Note**: Once initially configured, the allowed users list **cannot be managed via Ansible anymore**. It can only be managed subsequently via bot commands.
**If necessary**, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
**If necessary**, add the following configuration to your `vars.yml` file:
```yaml
# Uncomment and adjust the bot users if necessary:
@ -123,7 +130,7 @@ Configuring `matrix_bot_baibot_config_initial_global_config_user_patterns` is op
You are **not required** to define agents [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration) via Ansible. **To get started quickly**, you can **skip this section and define agents at runtime via chat commands** (following the bot's guidance).
Privileged users (like the [👮♂️ Administrator](#️-administrator-configuration), but potentially others too - see the upstream [🔒 access](https://github.com/etkecc/baibot/blob/main/docs/access.md) documentation) can **define agents dynamically at any time** via chat commands.
Privileged users (like the [👮♂️ Administrator](#️-administrator-configuration), but potentially others too — see the upstream [🔒 access](https://github.com/etkecc/baibot/blob/main/docs/access.md) documentation) can **define agents dynamically at any time** via chat commands.
The Ansible role includes preset variables for easily enabling some [🤖 agents](https://github.com/etkecc/baibot/blob/main/docs/agents.md) on various [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md) (e.g. OpenAI, etc).
# See `defaults/main.yml` in the baibot role for more configuration options.
```
If you'd like to use more than one model, take a look at the [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset) section below.
# See `defaults/main.yml` in the baibot role for more configuration options.
```
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/groq`.
# See `defaults/main.yml` in the baibot role for more configuration options.
```
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/mistral`.
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`.
@ -258,7 +257,7 @@ You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot
This provider allows you to use OpenAI-compatible API services like [OpenRouter](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openrouter), [Together AI](https://github.com/etkecc/baibot/blob/main/docs/providers.md#together-ai), etc.
Some of these popular services already have **shortcut** providers (see [supported providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md#supported-providers) leading to this one behind the scenes - this make it easier to get started.
Some of these popular services already have **shortcut** providers (see [supported providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md#supported-providers) leading to this one behind the scenes — this make it easier to get started.
As of this moment, the playbook does not include presets for any of these services, so you'll need to [Configuring additional agents (without a preset)](#configuring-additional-agents-without-a-preset).
@ -313,7 +312,7 @@ Because these are [statically](https://github.com/etkecc/baibot/blob/main/docs/c
💡 To figure out what to put in the `config` section, refer to the [☁️ provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md) page, which contains **sample configuration YAML for each provider**.
As with any [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md), defining them means they exist. To actually make use of them, they need to be configured as handlers globally or in a specific room - see [Mixing & matching models](https://github.com/etkecc/baibot/blob/main/docs/features.md#mixing--matching-models).
As with any [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md), defining them means they exist. To actually make use of them, they need to be configured as handlers globally or in a specific room — see [Mixing & matching models](https://github.com/etkecc/baibot/blob/main/docs/features.md#mixing--matching-models).
💡 You may also wish to use these new agents for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
**Note**: these are initial defaults for the bot's global configuration. As such, changing any of these values subsequently has no effect on the bot's behavior. **Once initially configured the global configuration cannot be managed Ansible**, but only via bot commands.
### Extending the configuration
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-baibot/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bot-baibot/templates/config.yaml.j2` for the bot's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_bot_baibot_configuration_extension_yaml` variable
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
@ -395,11 +403,13 @@ Send `!bai help` to the bot in the room to see the available commands.
You can also refer to the upstream [baibot](https://github.com/etkecc/baibot) project's documentation.
## Debugging
## Troubleshooting
As with all other services, you can find service logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by running something like`journalctl -fu matrix-bot-baibot`
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running`journalctl -fu matrix-bot-baibot`.
The default logging level for this service is `info`, but you can increase it to `debug` (or even `trace`) with the following additional configuration:
### Increase logging verbosity
The default logging level for this service is `info`. If you want to increase the verbosity to `debug` (or even `trace`), add the following configuration to your `vars.yml` file and re-run the playbook:
The playbook can install and configure [Buscarron](https://github.com/etkecc/buscarron) for you.
Buscarron is bot that receives HTTP POST submissions of web forms and forwards them to a Matrix room.
See the project's [documentation](https://github.com/etkecc/buscarron/blob/main/README.md) to learn what it does and why it might be useful to you.
## Adjusting DNS records
By default, this playbook installs Buscarron on the `buscarron.` subdomain (`buscarron.example.com`) and requires you to create a CNAME record for `buscarron`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -29,13 +45,11 @@ matrix_bot_buscarron_forms:
matrix_bot_buscarron_spamlist:[]# (optional) list of emails/domains/hosts (with wildcards support) that should be rejected automatically
```
### Adjusting the Buscarron URL
By default, this playbook installs Buscarron on the `buscarron.` subdomain (`buscarron.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
### Adjusting the Buscarron URL (optional)
By tweaking the `matrix_bot_buscarron_hostname` and `matrix_bot_buscarron_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to the domain used for Matrix services (`matrix.example.com`),
Once you've decided on the domain and path, **you may need to adjust your DNS** records to point the Buscarron domain to the Matrix server.
By default, you will need to create a CNAME record for `buscarron`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
After changing the domain, **you may need to adjust your DNS** records to point the Buscarron domain to the Matrix server.
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
### Extending the configuration
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-buscarron/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
## Installing
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
@ -95,4 +113,14 @@ Here is an example for the `contact` form:
If you get banned, you'd need to restart the process by running the playbook with `--tags=start` or running `systemctl restart matrix-bot-buscarron` on the server.
You can also refer to the upstream [documentation](https://github.com/etkecc/buscarron).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-buscarron`.
### Increase logging verbosity
The default logging level for this component is `INFO`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
# 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.
Talk to [ChatGPT](https://openai.com/blog/chatgpt/) via your favourite Matrix client!
See the project's [documentation](https://github.com/matrixgpt/matrix-chatgpt-bot/blob/main/README.md) to learn what it does and why it might be useful to you.
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
⚠️ **Warning**: Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
> [!WARNING]
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
To make sure the bot can read encrypted messages, it will need an encryption key, just like any other new user. While obtaining the access token, follow the prompts to setup a backup key. More information can be found in the [Element documentation](https://element.io/help#encryption6).
# Configuring the system promt used, needed if the bot is used for special tasks.
# Configuring the system prompt used, needed if the bot is used for special tasks.
# More information: https://github.com/mustvlad/ChatGPT-System-Prompts
matrix_bot_chatgpt_matrix_bot_prompt_prefix:'Instructions:\nYou are ChatGPT, a large language model trained by OpenAI.'
```
### Extending the configuration
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-chatgpt/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
@ -74,4 +93,6 @@ To use the bot, invite it to the room you specified on your `vars.yml` file (`/i
After the bot joins the room, you can send a message to it. When you do so, use the prefix if you configured it or mention the bot.
You can also refer to the upstream [documentation](https://github.com/matrixgpt/matrix-chatgpt-bot).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-chatgpt`.
The playbook can install and configure the [Draupnir](https://github.com/the-draupnir-project/Draupnir) moderation bot for you.
See the project's [documentation](https://github.com/the-draupnir-project/Draupnir/blob/main/README.md) to learn what it does and why it might be useful to you.
See the project's [documentation](https://the-draupnir-project.github.io/draupnir-documentation/) to learn what it does and why it might be useful to you.
This documentation page is about installing Draupnir in bot mode. As an alternative, you can run a multi-instance Draupnir deployment by installing [Draupnir in appservice mode](./configuring-playbook-appservice-draupnir-for-all.md) (called Draupnir-for-all) instead.
If your migrating from Mjolnir skip to [this section](#migrating-from-mjolnir-only-required-if-migrating).
If your migrating from [Mjolnir](configuring-playbook-bot-mjolnir.md), skip to [this section](#migrating-from-mjolnir-only-required-if-migrating).
## Prerequisites
### Register the bot account
The playbook does not automatically create users for you. You **need to register the bot user manually** before setting up the bot.
Generate a strong password for the bot. You can create one with a command like `pwgen -s 64 1`.
You can use the playbook to [register a new user](registering-users.md):
If you would like Draupnir to be able to deactivate users, move aliases, shutdown rooms, show abuse reports (see [below](#abuse-reports)), etc then it must be a server admin so you need to change `admin=no` to `admin=yes` in the command above.
### Obtain an access token
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
⚠️ **Warning**: Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
### Make sure the account is free from rate limiting
If your homeserver's implementation is Synapse, you will need to prevent it from rate limiting the bot's account. **This is a required step. If you do not configure it, Draupnir will crash.**
This can be done using Synapse's [Admin APIs](https://element-hq.github.io/synapse/latest/admin_api/user_admin_api.html#override-ratelimiting-for-users). They can be accessed both externally and internally.
To expose the APIs publicly, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file.
The APIs can also be accessed via [Synapse Admin](https://github.com/etkecc/synapse-admin), a web UI tool you can use to administrate users, rooms, media, etc. on your Matrix server. The playbook can install and configure Synapse Admin for you. For details about it, see [this page](configuring-playbook-synapse-admin.md).
**Note**: access to the APIs is restricted with a valid access token, so exposing them publicly should not be a real security concern. Still, doing so is not recommended for additional security. See [official Synapse reverse-proxying recommendations](https://element-hq.github.io/synapse/latest/reverse_proxy.html#synapse-administration-endpoints).
To discharge rate limiting, run the following command on systems that ship curl (note that it does not work on outdated Windows 10). Even if the APIs are not exposed to the internet, you should still be able to run the command on the homeserver locally. Before running it, make sure to replace `@bot.draupnir:example.com` with the MXID of your Draupnir:
```sh
curl --header "Authorization: Bearer <access_token>" -X POST https://matrix.example.com/_synapse/admin/v1/users/@bot.draupnir:example.com/override_ratelimit
```
You can obtain an access token for a homeserver admin account in the same way as you can do so for Draupnir itself. If you have made Draupnir an admin, you can just use the Draupnir token.
### Create a management room
Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room. Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room.
If you make the management room encrypted (E2EE), then you MUST enable and use Pantalaimon (see [below](#configuration-with-e2ee-support)).
> [!WARNING]
> Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element Web you can do this by going to the room's settings, clicking Advanced, and then copying the internal room ID. The room ID will look something like `!qporfwt:example.com`.
It is possible to make the management room encrypted (E2EE). If doing so, then you need to enable the native E2EE support (see [below](#native-e2ee-support)).
Finally invite the `@bot.draupnir:example.com` account you created earlier into the room.
Once you have created the room you need to copy the room ID so you can specify it on your `inventory/host_vars/matrix.example.com/vars.yml` file. In Element Web you can check the ID by going to the room's settings and clicking "Advanced". The room ID will look something like `!qporfwt:example.com`.
## End-to-End Encryption support
Decide whether you want to support having an encrypted management room or not. Draupnir can still protect encrypted rooms without encryption support enabled.
Refer to Draupnir's [documentation](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#protecting-encrypted-rooms) for more details about why you might want to care about encryption support for protected rooms.
### Disable Pantalaimon for Draupnir (since v2.0.0; optional)
It is known that running Draupnir along with Pantalaimon breaks all workflows that involve answering prompts with reactions.
If you are updating Draupnir from v1.x.x and have enabled Pantalaimon for it, you can disable Pantalaimon in favor of the native E2EE support. To disable Pantalaimon, remove the configuration `matrix_bot_draupnir_pantalaimon_use: true` from your `vars.yml` file.
**Note**: because the management room is still encrypted, disabling it without enabling the native E2EE support will break the management room.
### Native E2EE support
To enable the native E2EE support, you need to obtain an access token for Draupnir and set it on your `vars.yml` file.
Note that native E2EE requires a clean access token that has not touched E2EE so curl is recommended as a method to obtain it. **The access token obtained via Element Web does not work with it**. Refer to the documentation on [how to obtain an access token via curl](obtaining-access-tokens.md#obtain-an-access-token-via-curl).
To enable the native E2EE support, add the following configuration to your `vars.yml` file. Make sure to replace `CLEAN_ACCESS_TOKEN_HERE` with the access token you obtained just now.
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE`.
To enable the bot, add the following configuration to your `vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE` with the one of the room which you have created earlier.
### Create and invite the bot to the management room
Decide whether you want Draupnir to be capable of operating in end-to-end encrypted (E2EE) rooms. This includes the management room and the moderated rooms.
Before proceeding to the next step, run the playbook with the following command to create the bot user.
To support E2EE, Draupnir needs to [use Pantalaimon](configuring-playbook-pantalaimon.md).
**Note**: the `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
When using Pantalaimon, Draupnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
Then, invite the bot (`@bot.draupnir:example.com`) to its management room which you have created earlier.
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
### Make sure the account is free from rate limiting (optional, recommended)
If your homeserver's implementation is Synapse, you will need to prevent it from rate limiting the bot's account. **This is a highly recommended step. If you do not configure it, Draupnir performance will be degraded.**
This can be done using Synapse's [Admin APIs](https://element-hq.github.io/synapse/latest/admin_api/user_admin_api.html#override-ratelimiting-for-users). They can be accessed both externally and internally.
**Note**: access to the APIs is restricted with a valid access token, so exposing them publicly should not be a real security concern. Still, doing so is not recommended for additional security. See [official Synapse reverse-proxying recommendations](https://element-hq.github.io/synapse/latest/reverse_proxy.html#synapse-administration-endpoints).
The APIs can also be accessed via [Synapse Admin](https://github.com/etkecc/synapse-admin), a web UI tool you can use to administrate users, rooms, media, etc. on your Matrix server. The playbook can install and configure Synapse Admin for you. For details about it, see [this page](configuring-playbook-synapse-admin.md).
#### Add the configuration
To expose the APIs publicly, add the following configuration to your `vars.yml` file:
```yaml
# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
matrix_pantalaimon_enabled:true
# Tell Draupnir to use Pantalaimon
matrix_bot_draupnir_pantalaimon_use:true
# User name and password for the bot you have created above. Required when using Pantalaimon.
The playbook's `group_vars` will configure other required settings. If using this role separately without the playbook, you also need to configure the two URLs that Draupnir uses to reach the homeserver, one through Pantalaimon and one "raw". This example is taken from the playbook's `group_vars`:
#### Obtain an access token for admin account
```yaml
# Endpoint URL that Draupnir uses to interact with the Matrix homeserver (client-server API).
# Set this to the pantalaimon URL if you're using that.
matrix_bot_draupnir_homeserver_url:"{{ 'http://matrix-pantalaimon:8009' if matrix_bot_draupnir_pantalaimon_use else matrix_addons_homeserver_client_api_url }}"
Manual access to Synapse's Admin APIs requires an access token for a homeserver admin account. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
# Endpoint URL that Draupnir could use to fetch events related to reports (client-server API and /_synapse/),
# only set this to the public-internet homeserver client API URL, do NOT set this to the pantalaimon URL.
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
#### Run the `curl` command
To disable rate limiting, run the following command on systems that ship curl. Before running it, make sure to replace:
-`ADMIN_ACCESS_TOKEN_HERE` with the access token of the admin account
-`example.com` with your base domain
-`@bot.draupnir:example.com` with the MXID of your Draupnir bot user
```sh
curl --header "Authorization: Bearer ADMIN_ACCESS_TOKEN_HERE" -X POST https://matrix.example.com/_synapse/admin/v1/users/@bot.draupnir:example.com/override_ratelimit
```
#### Configuration without E2EE support
When NOT using Pantalaimon, Draupnir does not log in by itself and you must give it an access token for its bot account.
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
- This does not work on outdated Windows 10 as curl is not available there.
- Even if the APIs are not exposed to the internet, you should still be able to run the command on the homeserver locally.
### Abuse Reports
Draupnir supports two methods to receive reports in the management room.
Draupnir can receive reports in the management room.
The first method intercepts 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:
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.
The other method polls an Synapse Admin API endpoint, hence it is available only if using Synapse and if the Draupnir user is an admin (see [above](#register-the-bot-account)). To enable it, set `pollReports: true` on `vars.yml` file as below.
-->
### Extending the configuration
You can configure additional options by adding the `matrix_bot_draupnir_configuration_extension_yaml` variable.
There are some additional things you may wish to configure about the bot.
For example, to change Draupnir's `pollReports` option to `true`, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
Take a look at:
-`roles/custom/matrix-bot-draupnir/defaults/main.yml` for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_bot_draupnir_configuration_extension_yaml` variable
For example, to change Draupnir's `acceptInvitesFromSpace` option to `!qporfwt:example.com`, add the following configuration to your `vars.yml` file:
### Migrating from Mjolnir (Only required if migrating)
Replace your `matrix_bot_mjolnir` config with `matrix_bot_draupnir` config. Also disable Mjolnir if you're doing migration.
Note that Draupnir supports E2EE natively, so you can enable it instead of Pantalaimon. It is recommended to consult the instruction [here](#native-e2ee-support).
That is all you need to do due to that Draupnir can complete migration on its own.
`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 Pantalaimon's password (`matrix_bot_draupnir_pantalaimon_password` in your `vars.yml` file) subsequently, its credentials on the homeserver won't be updated automatically. If you'd like to change the password, use a tool like [synapse-admin](configuring-playbook-synapse-admin.md) to change it, and then update `matrix_bot_draupnir_pantalaimon_password` to let Pantalaimon know its new password.
- 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
@ -204,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`
@ -236,7 +274,7 @@ You can also **turn on various built-in [protections](https://the-draupnir-proje
To **see which protections are available and which are enabled**, send a `!draupnir protections` command to the Management Room.
To **see the configuration options for a given protection**, send a `!draupnir config get PROTECTION_NAME` (e.g. `!draupnir config get JoinWaveShortCircuit`).
To **see the configuration options for a given protection**, send a `!draupnir protections show PROTECTION_NAME` (e.g. `!draupnir protections show JoinWaveShortCircuit`).
To **set a specific option for a given protection**, send a command like this: `!draupnir config set PROTECTION_NAME.OPTION VALUE` (e.g. `!draupnir config set JoinWaveShortCircuit.timescaleMinutes 30`).
**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.
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
⚠️ **Warning**: Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
> [!WARNING]
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
## Adjusting DNS records
By default, this playbook installs Go-NEB on the `goneb.` subdomain (`goneb.example.com`) and requires you to create a CNAME record for `goneb`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
@ -194,47 +211,46 @@ matrix_bot_go_neb_services:
msg_type:"m.text"# Must be either `m.text` or `m.notice`
```
### Adjusting the Go-NEB URL
By default, this playbook installs Go-NEB on the `goneb.` subdomain (`goneb.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
### Adjusting the Go-NEB URL (optional)
By tweaking the `matrix_bot_go_neb_hostname` and `matrix_bot_go_neb_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to the domain used for Matrix services (`matrix.example.com`),
# so we won't need to add additional DNS records for Go-NEB.
Once you've decided on the domain and path, **you may need to adjust your DNS** records to point the Go-NEB domain to the Matrix server.
By default, you will need to create a CNAME record for `goneb`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
After changing the domain, **you may need to adjust your DNS** records to point the Go-NEB domain to the Matrix server.
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
### Extending the configuration
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-go-neb/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bot-go-neb/templates/config.yaml.j2` for the bot's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_bot_go_neb_configuration_extension_yaml` 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 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
@ -245,3 +261,7 @@ Basic usage is like this: `!echo hi` or `!imgur puppies` or `!giphy matrix`
If you enabled the github_cmd service, send `!github help` to the bot in the room to see the available commands.
You can also refer to the upstream [Documentation](https://github.com/matrix-org/go-neb).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-go-neb`.
The playbook can install and configure [Honoroit](https://github.com/etkecc/honoroit) for you.
@ -6,6 +14,12 @@ It's a bot you can use to setup **your own helpdesk on matrix**
See the project's [documentation](https://github.com/etkecc/honoroit/blob/main/README.md) to learn what it does and why it might be useful to you.
## Adjusting DNS records (optional)
By default, this playbook installs Honoroit on the `matrix.` subdomain, at the `/honoroit` path (https://matrix.example.com/honoroit). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
If you wish to adjust it, see the section [below](#adjusting-the-honoroit-url-optional) for details about DNS configuration.
## Adjusting the playbook configuration
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
By default, this playbook installs Honoroit on the `matrix.` subdomain, at the `/honoroit` path (https://matrix.example.com/honoroit). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
### Adjusting the Honoroit URL (optional)
By tweaking the `matrix_bot_honoroit_hostname` and `matrix_bot_honoroit_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
If you've changed the default hostname, you may need to create a CNAME record for the Honoroit domain (`honoroit.example.com`), which targets `matrix.example.com`.
If you've changed the default hostname, **you may need to adjust your DNS** records to point the Honoroit domain to the Matrix server.
When setting, replace `example.com` with your own.
See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
If you've decided to use the default hostname, you won't need to do any extra DNS configuration.
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-honoroit/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
## Installing
@ -73,3 +89,15 @@ After the bot joins the room, any Matrix user can send a message to it to start
Send `!ho help` to the bot in the room to see the available commands.
You can also refer to the upstream [documentation](https://github.com/etkecc/honoroit#features).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-honoroit`.
### Increase logging verbosity
If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-matrix-registration-bot/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bot-matrix-registration-bot/templates/config.yaml.j2` for the bridge's default configuration
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
@ -56,10 +77,23 @@ 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:
```sh
just run-tags bot-matrix-registration-bot-clean-cache
```
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-matrix-registration-bot`.
### Increase logging verbosity
The default logging level for this component is `INFO`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-matrix-reminder-bot/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bot-matrix-reminder-bot/templates/config.yaml.j2` for the bot's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_bot_matrix_reminder_bot_configuration_extension_yaml` variable
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
@ -53,3 +70,18 @@ Basic usage is like this: `!remindme in 2 minutes; This is a test`
Send `!help reminders` to the room to see the bot's help menu for additional commands.
You can also refer to the upstream [Usage documentation](https://github.com/anoadragon453/matrix-reminder-bot#usage).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-matrix-reminder-bot`.
### Increase logging verbosity
The default logging level for this component is `INFO`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
The playbook can install and configure [maubot](https://github.com/maubot/maubot) for you.
@ -6,6 +17,12 @@ After setting up maubot, you can use the web management interface to make it do
See the project's [documentation](https://docs.mau.fi/maubot/usage/basic.html) to learn what it does and why it might be useful to you.
## Adjusting DNS records (optional)
By default, this playbook installs maubot on the `matrix.` subdomain, at the `/_matrix/maubot/` path (https://matrix.example.com/_matrix/maubot/). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**.
If you wish to adjust it, see the section [below](#adjusting-the-maubot-url-optional) for details about DNS configuration.
## Adjusting the playbook configuration
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -25,13 +42,11 @@ matrix_bot_maubot_admins:
You can add multiple admins. The admin accounts are only used to access the maubot administration interface.
### Adjusting the maubot URL
By default, this playbook installs maubot on the `matrix.` subdomain, at the `/_matrix/maubot/` path (https://matrix.example.com/_matrix/maubot/). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
### Adjusting the maubot URL (optional)
By tweaking the `matrix_bot_maubot_hostname` and `matrix_bot_maubot_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
If you've changed the default hostname, you may need to create a CNAME record for the maubot domain (`maubot.example.com`), which targets `matrix.example.com`.
If you've changed the default hostname, **you may need to adjust your DNS** records to point the maubot domain to the Matrix server.
When setting, replace `example.com` with your own.
See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
If you've decided to use the default hostname, you won't need to do any extra DNS configuration.
There are some additional things you may wish to configure about the bot.
Take a look at:
-`roles/custom/matrix-bot-maubot/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bot-maubot/templates/config.yaml.j2` for the bot's default configuration
## Customizing the maubot container image
Certain [maubot plugins](https://plugins.mau.bot/) require additional dependencies to be installed.
You can customize the default maubot container image and install your own dependencies.
Example additional configuration for your `vars.yml` file:
Consult the [Dockerfile reference](https://docs.docker.com/reference/dockerfile/) for more information about the syntax.
## Installing
@ -81,4 +120,18 @@ This can be done via `mbc login` then `mbc auth` (see the [maubot documentation]
Alternatively, you can refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md). Be aware that you'd better use the **Obtain an access token via curl** method (not **Obtain an access token via Element Web**) as the latter will causes issues to your bot in encrypted rooms. Read [more](https://docs.mau.fi/maubot/usage/basic.html#creating-clients).
⚠️ **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.
> [!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.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-maubot`.
### Increase logging verbosity
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
The playbook can install and configure the [Mjolnir](https://github.com/matrix-org/mjolnir) moderation bot for you.
@ -24,7 +35,8 @@ If you would like Mjolnir to be able to deactivate users, move aliases, shutdown
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
⚠️ **Warning**: Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
> [!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.
### Make sure the account is free from rate limiting
@ -32,37 +44,57 @@ If your homeserver's implementation is Synapse, you will need to prevent it from
This can be done using Synapse's [Admin APIs](https://element-hq.github.io/synapse/latest/admin_api/user_admin_api.html#override-ratelimiting-for-users). They can be accessed both externally and internally.
To expose the APIs publicly, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file.
**Note**: access to the APIs is restricted with a valid access token, so exposing them publicly should not be a real security concern. Still, doing so is not recommended for additional security. See [official Synapse reverse-proxying recommendations](https://element-hq.github.io/synapse/latest/reverse_proxy.html#synapse-administration-endpoints).
The APIs can also be accessed via [Synapse Admin](https://github.com/etkecc/synapse-admin), a web UI tool you can use to administrate users, rooms, media, etc. on your Matrix server. The playbook can install and configure Synapse Admin for you. For details about it, see [this page](configuring-playbook-synapse-admin.md).
#### Add the configuration
To expose the APIs publicly, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
The APIs can also be accessed via [Synapse Admin](https://github.com/etkecc/synapse-admin), a web UI tool you can use to administrate users, rooms, media, etc. on your Matrix server. The playbook can install and configure Synapse Admin for you. For details about it, see [this page](configuring-playbook-synapse-admin.md).
#### Obtain an access token for admin account
**Note**: access to the APIs is restricted with a valid access token, so exposing them publicly should not be a real security concern. Still, doing so is not recommended for additional security. See [official Synapse reverse-proxying recommendations](https://element-hq.github.io/synapse/latest/reverse_proxy.html#synapse-administration-endpoints).
Manual access to Synapse's Admin APIs requires an access token for a homeserver admin account. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md). If you have made Mjolnir an admin, you can just use the Mjolnir token.
To discharge rate limiting, run the following command on systems that ship curl (note that it does not work on outdated Windows 10). Even if the APIs are not exposed to the internet, you should still be able to run the command on the homeserver locally. Before running it, make sure to replace `@bot.mjolnir:example.com` with the MXID of your Mjolnir:
> [!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.
#### Run the `curl` command
To disable rate limiting, run the following command on systems that ship curl. Before running it, make sure to replace:
-`ADMIN_ACCESS_TOKEN_HERE` with the access token of the admin account
-`example.com` with your base domain
-`@bot.mjolnir:example.com` with the MXID of your Mjolnir bot user
```sh
curl --header "Authorization: Bearer <access_token>" -X POST https://matrix.example.com/_synapse/admin/v1/users/@bot.mjolnir:example.com/override_ratelimit
curl --header "Authorization: Bearer ADMIN_ACCESS_TOKEN_HERE" -X POST https://matrix.example.com/_synapse/admin/v1/users/@bot.mjolnir:example.com/override_ratelimit
```
You can obtain an access token for a homeserver admin account in the same way as you can do so for Mjolnir itself. If you have made Mjolnir an admin, you can just use the Mjolnir token.
**Notes**:
- This does not work on outdated Windows 10 as curl is not available there.
- Even if the APIs are not exposed to the internet, you should still be able to run the command on the homeserver locally.
### Create a management room
Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room. Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room.
If you make the management room encrypted (E2EE), then you MUST enable and use Pantalaimon (see [below](#configuration-with-e2ee-support)).
> [!WARNING]
> Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element Web you can do this by going to the room's settings, clicking Advanced, and then copying the internal room ID. The room ID will look something like `!qporfwt:example.com`.
It is possible to make the management room encrypted (E2EE). If doing so, then you MUST enable and use Pantalaimon (see [below](#configuration-with-e2ee-support)).
Once you have created the room you need to copy the room ID so you can specify it on your `vars.yml` file. In Element Web you can check the ID by going to the room's settings and clicking "Advanced". The room ID will look something like `!qporfwt:example.com`.
Finally invite the `@bot.mjolnir:example.com` account you created earlier into the room.
## Adjusting the playbook configuration
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE`.
To enable the bot, add the following configuration to your `vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE` with the one of the room which you have created just now.
```yaml
# Enable Mjolnir
@ -81,7 +113,7 @@ To support E2EE, Mjolnir needs to [use Pantalaimon](configuring-playbook-pantala
When using Pantalaimon, Mjolnir will log in to its bot account itself through Pantalaimon, so configure its username and password.
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
Add the following configuration to your `vars.yml` file (adapt to your needs):
```yaml
# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
When NOT using Pantalaimon, Mjolnir does not log in by itself and you must give it an access token for its bot account.
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
Add the following configuration to your `vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
To enable Mjolnir synapse antispam module, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file (adapt to your needs):
To enable Mjolnir synapse antispam module, add the following configuration to your `vars.yml` file (adapt to your needs):
You can configure additional options by adding the `matrix_bot_mjolnir_configuration_extension_yaml` variable to your `inventory/host_vars/matrix.example.com/vars.yml` file.
There are some additional things you may wish to configure about the bot.
For example, to change Mjolnir's `recordIgnoredInvites` option to `true`, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
Take a look at:
-`roles/custom/matrix-bot-mjolnir/defaults/main.yml` for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_bot_mjolnir_configuration_extension_yaml` variable
For example, to change Mjolnir's `recordIgnoredInvites` option to `true`, add the following configuration to your `vars.yml` file:
```yaml
matrix_bot_mjolnir_configuration_extension_yaml:|
@ -153,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.
You can refer to the upstream [documentation](https://github.com/matrix-org/mjolnir) for additional ways to use and configure Mjolnir. Check out their [quickstart guide](https://github.com/matrix-org/mjolnir#quickstart-guide) for some basic commands you can give to the bot.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-mjolnir`.
### Increase logging verbosity
The default logging level for this component is `INFO`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
# 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.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-appservice-discord/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-appservice-discord/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_appservice_discord_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`
- 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.
## Self-Service Bridging (Manual)
Self-service bridging allows you to bridge specific and existing Matrix rooms to specific Discord rooms. To enable it, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
Self-service bridging allows you to bridge specific and existing Matrix rooms to specific Discord rooms. To enable it, add the following configuration to your `vars.yml` file:
@ -73,7 +88,7 @@ Through portal bridging, Matrix rooms will automatically be created by the bot a
All Matrix rooms created this way are **listed publicly** by default, and you will not have admin permissions to change this. To get more control, [make yourself a room Administrator](#getting-administrator-access-in-a-portal-bridged-room). You can then unlist the room from the directory and change the join rules.
To disable portal bridging, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
To disable portal bridging, add the following configuration to your `vars.yml` file:
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-discord`.
### 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 (adapt to your needs) and re-run the playbook:
**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.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-appservice-irc/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-appservice-irc/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_appservice_irc_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`
- 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
To use the bridge, you need to start a chat with `@irc_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-irc`.
### Configuring for logging
The default logging level for this component is `debug`, and the log is output to the console only. If you want to change the verbosity or enable logging to a file, add the following configuration to your `vars.yml` file (adapt to your needs) and re-run the playbook:
# 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. `matrix-appservice-kakaotalk` is a bridge to [Kakaotalk](https://www.kakaocorp.com/page/service/service/KakaoTalk?lang=ENG) based on [node-kakao](https://github.com/storycraft/node-kakao) (now unmaintained) and some [mautrix-facebook](https://github.com/mautrix/facebook) code.
⚠️ **Warning**: there have been recent reports (~2022-09-16) that **using this bridge may get your account banned**.
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.
See the project's [documentation](https://src.miscworks.net/fair/matrix-appservice-kakaotalk/src/branch/master/README.md) to learn what it does and why it might be useful to you.
> [!WARNING]
> There have been recent reports (~2022-09-16) that **using this bridge may get your account banned**.
## Prerequisite (optional)
### Enable Shared Secret Auth
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
@ -20,9 +34,7 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_appservice_kakaotalk_enabled:true
```
You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
### Additional configuration
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
@ -37,41 +49,27 @@ 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
To use the bridge, you need to start a chat with `@kakaotalkbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `login --save EMAIL_OR_PHONE_NUMBER` to the bridge bot to enable bridging for your Kakaotalk account. The `--save` flag may be omitted, if you'd rather not save your password.
You then need to send `login --save EMAIL_OR_PHONE_NUMBER` to the bridge bot to enable bridging for your Kakaotalk account. The `--save` flag may be omitted, if you'd rather not save your password.
### 💡 Set up Double Puppeting
## Troubleshooting
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-kakaotalk`.
To set it up, you have 2 ways of going about it.
### Increase logging verbosity
#### Method 1: automatically, by enabling Shared Secret Auth
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
The bridge automatically performs Double Puppeting if [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Appservice-Kakaotalk` device some time in the future, as that would break the Double Puppeting feature
Other configuration options are available via the `matrix_appservice_slack_configuration_extension_yaml` variable.
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-appservice-slack/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-appservice-slack/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_appservice_slack_configuration_extension_yaml` variable
For example, to change the bot's username from `slackbot`, add the following configuration to your `vars.yml` file. Replace `examplebot` with your own.
@ -69,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.
## Usage
@ -86,7 +107,7 @@ To use the bridge, you need to send `/invite @slackbot:example.com` to invite th
If Team Sync is not enabled, for each channel you would like to bridge, perform the following steps:
- Create a Matrix room in the usual manner for your client. Take a note of its Matrix room ID - it will look something like `!qporfwt:example.com`.
- Create a Matrix room in the usual manner for your client. Take a note of its Matrix room ID — it will look something like `!qporfwt:example.com`.
- Invite the bot user to both the Slack and Matrix channels you would like to bridge using `/invite @matrixbot` for Slack and `/invite @slackbot:example.com` for Matrix.
- Determine the "channel ID" that Slack uses to identify the channel. You can see it when you open a given Slack channel in a browser. The URL reads like this: `https://app.slack.com/client/XXX/<the channel ID>/details/`.
- Issue a link command in the administration control room with these collected values as arguments:
@ -121,7 +142,7 @@ Unlinking doesn't only disconnect the bridge, but also makes the slackbot leave
## Troubleshooting
As always, check the logs: `journalctl -fu matrix-appservice-slack`
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-slack`.
### Linking: "Room is now pending-name"
@ -129,8 +150,8 @@ This typically means that you haven't used the correct Slack channel ID. Unlink
### Messages work from Matrix to Slack, but not the other way around
Check you logs, if they say something like
Check the logs, and if you find the message like below, unlink your room, reinvite the bot and re-link it again.
`WARN SlackEventHandler Ignoring message from unrecognised Slack channel ID : %s (%s) <thechannelID><someotherID>`
then unlink your room, reinvite the bot and re-link it again. This may particularly hit you, if you tried to unsuccessfully link your room multiple times without unlinking it after each failed attempt.
This may particularly hit you, if you tried to unsuccessfully link your room multiple times without unlinking it after each failed attempt.
# 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.
@ -14,9 +25,6 @@ To enable the bridge, add the following configuration to your `inventory/host_va
# Uncomment to increase the verbosity of logging via `journalctl -fu matrix-appservice-webhooks.service`
# matrix_appservice_webhooks_log_level: 'verbose'
# As of Synapse 1.90.0, uncomment to enable the backwards compatibility (https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900) that this bridge needs.
# Note: This deprecated method is considered insecure.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-appservice-webhooks/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-appservice-webhooks/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_appservice_webhooks_configuration_extension_yaml` variable
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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
@ -48,7 +61,7 @@ To use the bridge, you need to invite the bridge bot user to your room in either
- Send `/invite @_webhook:example.com` (**Note**: Make sure you have administration permissions in your room)
- Add the bridge bot to a private channel (personal channels imply you being an administrator)
You then need to send a message to the bridge bot in order to receive a private message including the webhook link:
You then need to send a message to the bridge bot to receive a private message including the webhook link:
```
!webhook
@ -85,3 +98,16 @@ If you're using the [Dimension integration manager](configuring-playbook-dimensi
To configure it, open the Dimension integration manager, and go to "Settings" and "Bridges", then select edit action for "Webhook Bridge".
On the UI, press "Add self-hosted Bridge" button and populate "Provisioning URL" and "Shared Secret" values from `/matrix/appservice-webhooks/config/config.yaml` file's homeserver URL value and provisioning secret value, respectively.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-webhooks`.
### Increase logging verbosity
The default logging level for this component is `info`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
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 other mautrix bridges
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.
See the project's [documentation](https://github.com/beeper/linkedin/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisite
### Enable Appservice Double Puppet or Shared Secret Auth (optional)
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) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.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.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -12,25 +32,13 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_beeper_linkedin_enabled:true
```
There are some additional things you may wish to configure about the bridge before you continue.
### Extending the configuration
Encryption support is off by default. If you would like to enable encryption, add the following to your `vars.yml` file:
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
If you would like to be able to administrate the bridge from your account it can be configured like this:
You may wish to look at `roles/custom/matrix-bridge-beeper-linkedin/templates/config.yaml.j2` to find other things you would like to configure.
**Note**: when following the guide to configure the bridge, make sure to replace `_mautrix_SERVICENAME_` in the variable names with `_beeper_linkedin_`.
## Installing
@ -38,37 +46,31 @@ 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.
## Set up Double Puppeting by enabling Appservice Double Puppet or Shared Secret Auth
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
## Usage
To use the bridge, you need to start a chat with `@linkedinbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `login YOUR_LINKEDIN_EMAIL_ADDRESS` to the bridge bot to enable bridging for your LinkedIn account.
If you run into trouble, check the [Troubleshooting](#troubleshooting) section below.
After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting-by-enabling-appservice-double-puppet-or-shared-secret-auth), if you haven't already done so.
You then need to send `login YOUR_LINKEDIN_EMAIL_ADDRESS` to the bridge bot to enable bridging for your LinkedIn account.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-beeper-linkedin`.
### Increase logging verbosity
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
```yaml
matrix_beeper_linkedin_logging_level:DEBUG
```
### Bridge asking for 2FA even if you don't have 2FA enabled
If you don't have 2FA enabled and are logging in from a strange IP for the first time, LinkedIn will send an email with a one-time code. You can use this code to authorize the bridge session. In my experience, once the IP is authorized, you will not be asked again.
The playbook can install and configure [go-skype-bridge](https://github.com/kelaresg/go-skype-bridge) for you.
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.
See the project's [documentation](https://github.com/kelaresg/go-skype-bridge/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisite (optional)
### Enable Shared Secret Auth
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
To enable the [Skype](https://www.skype.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
matrix_go_skype_bridge_enabled:true
```
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
**Note**: when following the guide to configure the bridge, make sure to replace `_mautrix_SERVICENAME_` in the variable names with `_go_skype_bridge_`.
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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
To use the bridge, you need to start a chat with `Skype bridge bot` with the handle `@skypebridgebot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
To use the bridge, you need to start a chat with `@skypebridgebot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `help` to the bot to see the available commands.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-go-skype-bridge`.
### Increase logging verbosity
The default logging level for this component is `warn`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
# 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.
The playbook can install and configure [Heisenbridge](https://github.com/hifi/heisenbridge) - the bouncer-style [IRC](https://en.wikipedia.org/wiki/Internet_Relay_Chat) bridge for you.
The playbook can install and configure [Heisenbridge](https://github.com/hifi/heisenbridge) — the bouncer-style [IRC](https://en.wikipedia.org/wiki/Internet_Relay_Chat) bridge for you.
See the project's [documentation](https://github.com/hifi/heisenbridge/blob/master/README.md) to learn what it does and why it might be useful to you. You can also take a look at [this demonstration video](https://www.youtube.com/watch?v=nQk1Bp4tk4I).
## Configuration
## Adjusting DNS records (optional)
By default, this playbook installs Heisenbridge on the `matrix.` subdomain, at the `/heisenbridge` path (https://matrix.example.com/heisenbridge). It would handle media requests there (see the [release notes for Heisenbridge v1.15.0](https://github.com/hifi/heisenbridge/releases/tag/v1.15.0)). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
If you wish to adjust it, see the section [below](#adjusting-the-heisenbridge-url-optional) for details about DNS configuration.
## Adjusting the playbook configuration
To enable Heisenbridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
For a more complete list of variables that you could override, see the [`defaults/main.yml` file](../roles/custom/matrix-bridge-heisenbridge/defaults/main.yml) of the Heisenbridge Ansible role.
### Adjusting the Heisenbridge URL
By default, this playbook installs Heisenbridge on the `matrix.` subdomain, at the `/heisenbridge` path (https://matrix.example.com/heisenbridge). It would handle media requests there (see the [release notes for Heisenbridge v1.15.0](https://github.com/hifi/heisenbridge/releases/tag/v1.15.0)).
This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
### Adjusting the Heisenbridge URL (optional)
By tweaking the `matrix_heisenbridge_hostname` and `matrix_heisenbridge_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
If you've changed the default hostname, you may need to create a CNAME record for the Heisenbridge domain (`heisenbridge.example.com`), which targets `matrix.example.com`.
If you've changed the default hostname, **you may need to adjust your DNS** records to point the Heisenbridge domain to the Matrix server.
When setting, replace `example.com` with your own.
See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
If you've decided to use the default hostname, you won't need to do any extra DNS configuration.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-heisenbridge/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
## Installing
@ -53,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.
## Usage
@ -73,3 +81,7 @@ Help is available for all commands with the `-h` switch.
You can also learn the basics by watching [this demonstration video](https://www.youtube.com/watch?v=nQk1Bp4tk4I).
If you encounter issues or feel lost you can join the project room at [#heisenbridge:vi.fi](https://matrix.to/#/#heisenbridge:vi.fi) for help.
## 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-heisenbridge`.
The playbook can install and configure [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) for you.
@ -38,7 +48,12 @@ Take special note of the `matrix_hookshot_*_enabled` variables. Services that ne
### Extending the configuration
You can configure additional options by adding the `matrix_hookshot_configuration_extension_yaml` and `matrix_hookshot_registration_extension_yaml` variables.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-hookshot/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-hookshot/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_hookshot_configuration_extension_yaml` and `matrix_hookshot_registration_extension_yaml` variables
Refer the [official instructions](https://matrix-org.github.io/matrix-hookshot/latest/setup.html) and the comments in [main.yml](../roles/custom/matrix-bridge-hookshot/defaults/main.yml) to learn what the individual options do.
@ -88,12 +103,10 @@ Unless indicated otherwise, the following endpoints are reachable on your `matri
| metrics | `/metrics/hookshot` | `matrix_hookshot_metrics_enabled` and exposure enabled via `matrix_hookshot_metrics_proxying_enabled` or `matrix_metrics_exposure_enabled`. Read more in the [Metrics section](#metrics) below. | Prometheus |
Also see the various `matrix_hookshot_container_labels_*` variables in [main.yml](../roles/custom/matrix-bridge-hookshot/defaults/main.yml), which expose URLs publicly
Also see the various `matrix_hookshot_container_labels_*` variables in [main.yml](../roles/custom/matrix-bridge-hookshot/defaults/main.yml), which expose URLs publicly.
The different listeners are also reachable *internally* in the docker-network via the container's name (configured by `matrix_hookshot_container_url`) and on different ports (e.g. `matrix_hookshot_appservice_port`). Read [main.yml](../roles/custom/matrix-bridge-hookshot/defaults/main.yml) in detail for more info.
@ -105,36 +118,68 @@ The GitHub bridge requires you to install a private key file. This can be done i
- somehow copy the file to the path `{{ matrix_hookshot_base_path }}/{{ matrix_hookshot_github_private_key_file }}` (default: `/matrix/hookshot/private-key.pem`) on the server manually.
- use the [`aux` role](https://github.com/mother-of-all-self-hosting/ansible-role-aux) to copy the file from an arbitrary path on your ansible client to the correct path on the server.
To use the `aux` role, make sure the `matrix_hookshot_github_private_key` variable is empty. Then add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
To use the `aux` role, make sure the `matrix_hookshot_github_private_key` variable is empty. Then add the following configuration to your `vars.yml` file:
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`.
### Metrics
Metrics are **only enabled by default** if the builtin [Prometheus](configuring-playbook-prometheus-grafana.md) is enabled (by default, Prometheus isn't enabled). If so, metrics will automatically be collected by Prometheus and made available in Grafana. You will, however, need to set up your own Dashboard for displaying them.
To explicitly enable metrics, use `matrix_hookshot_metrics_enabled: true`. This only exposes metrics over the container network, however.
**To collect metrics from an external Prometheus server**, besides enabling metrics as described above, you will also need to enable metrics exposure on `https://matrix.example.com/metrics/hookshot` by:
- either enabling metrics exposure for Hookshot via `matrix_hookshot_metrics_proxying_enabled: true`
- or enabling metrics exposure for all services via `matrix_metrics_exposure_enabled: true`
Whichever one you go with, by default metrics are exposed publicly **without** password-protection. See [the Prometheus and Grafana docs](configuring-playbook-prometheus-grafana.md) for details about password-protection for metrics.
### Collision with matrix-appservice-webhooks
If you are also running [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), it reserves its namespace by the default setting `matrix_appservice_webhooks_user_prefix: '_webhook_'`. You should take care if you modify its or hookshot's prefix that they do not collide with each other's namespace (default `matrix_hookshot_generic_userIdPrefix: '_webhooks_'`).
### Enable metrics
The playbook can enable and configure the metrics of the service for you.
Metrics are **only enabled by default** if the builtin [Prometheus](configuring-playbook-prometheus-grafana.md) is enabled (by default, Prometheus isn't enabled). If so, metrics will automatically be collected by Prometheus and made available in Grafana. You will, however, need to set up your own Dashboard for displaying them.
To enable the metrics, add the following configuration to your `vars.yml` file:
```yaml
# Expose metrics (locally, on the container network).
matrix_hookshot_metrics_enabled:true
```
**To collect metrics from an external Prometheus server**, besides enabling metrics as described above, you will also need to enable metrics exposure on `https://matrix.example.com/metrics/hookshot` by adding the following configuration to your `vars.yml` file:
```yaml
matrix_hookshot_metrics_proxying_enabled:true
```
By default metrics are exposed publicly **without** password-protection. To password-protect the metrics with dedicated credentials, add the following configuration to your `vars.yml` file:
To `matrix_hookshot_container_labels_metrics_middleware_basic_auth_users`, set the Basic Authentication credentials (raw `htpasswd` file content) used to protect the endpoint. See https://doc.traefik.io/traefik/middlewares/http/basicauth/#users for details about it.
**Note**: alternatively, you can use `matrix_metrics_exposure_enabled` to expose all services on this `/metrics/*` feature, and you can use `matrix_metrics_exposure_http_basic_auth_enabled` and `matrix_metrics_exposure_http_basic_auth_users` to password-protect the metrics of them. See [this section](configuring-playbook-prometheus-grafana.md#collecting-metrics-to-an-external-prometheus-server) for more information.
#### Enable Grafana (optional)
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.
## 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-hookshot`.
### 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 [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) for you.
See the project's [documentation](https://github.com/benkuly/matrix-sms-bridge/blob/master/README.md) to learn what it does and why it might be useful to you.
**The bridge uses [android-sms-gateway-server](https://github.com/RebekkaMa/android-sms-gateway-server). You need to configure it first.**
## Prerequisite
The bridge uses [android-sms-gateway-server](https://github.com/RebekkaMa/android-sms-gateway-server). You need to configure it first.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-sms/defaults/main.yml` for some variables that you can customize via your `vars.yml` file. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_sms_bridge_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`
- 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
Read the [user guide](https://github.com/benkuly/matrix-sms-bridge/blob/master/README.md#user-guide) to see how this bridge works.
## 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-sms-bridge`.
<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.
The author of the bridges maintains [the official docs](https://docs.mau.fi/bridges/index.html), whose source code is available at [mautrix/docs](https://github.com/mautrix/docs) repository on GitHub. You may as well to refer it while configuring them.
You can see each bridge's features on the `ROADMAP.md` file in its corresponding mautrix repository.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
# Replace SERVICENAME with one of: twitter, discord, signal, googlechat, etc.
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).
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.
### Configure bridge permissions (optional)
By default any user on your homeserver will be able to use the mautrix bridges. To limit who can use them you would need to configure their permissions settings.
Different levels of permission can be granted to users. For example, to **configure a user as an administrator for all bridges**, add the following configuration to your `vars.yml` file:
```yaml
matrix_admin:"@alice:{{ matrix_domain }}"
```
If you don't define the `matrix_admin` in your configuration (e.g. `matrix_admin: @alice:example.com`), then there's no admin by default.
**Alternatively** (more verbose, but allows multiple admins to be configured), you can do the same on a per-bridge basis with:
This will add the admin permission to the specific user, while keeping the default permissions.
You could also redefine the default permissions settings completely, rather than adding extra permissions. You may wish to look at `roles/custom/matrix-bridge-mautrix-SERVICENAME/templates/config.yaml.j2` to find information on the permission settings and other options you would like to configure.
### Enable encryption (optional)
[Encryption (End-to-Bridge Encryption, E2BE) support](https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html) is off by default. If you would like to enable encryption, add the following configuration to your `vars.yml` file:
[Relay mode](https://docs.mau.fi/bridges/general/relay-mode.html) is off by default. Check [the table on the official documentation](https://docs.mau.fi/bridges/general/relay-mode.html#support-table) for bridges which support relay mode.
If you would like to enable it, add the following configuration to your `vars.yml` file:
You can only have one `matrix_mautrix_SERVICENAME_configuration_extension_yaml` definition in `vars.yml` per bridge, so if you need multiple pieces of configuration there, just merge them like this:
If you want to activate the relaybot in a room, send `!prefix set-relay` in the rooms where you want to use the bot (replace `!prefix` with the appropriate command prefix for the bridge, like `!signal` or `!wa`). To deactivate, send `!prefix unset-relay`.
Use `!prefix set-pl 100` to be able for the bot to modify room settings and invite others.
#### Allow anyone on the homeserver to become a relay user (optional)
By default, only admins are allowed to set themselves as relay users. To allow anyone on your homeserver to set themselves as relay users, add the following configuration to your `vars.yml` file:
To specify the logging level, add the following configuration to your `vars.yml` file:
```yaml
matrix_mautrix_SERVICENAME_logging_level:warn
```
Replace `warn` with one of the following to control the verbosity of the logs generated: `trace`, `debug`, `info`, `warn`, `error` or `fatal`.
If you have issues with a service, and are requesting support, the higher levels of logging (those that appear earlier in the list, like `trace`) will generally be more helpful.
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-mautrix-SERVICENAME/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-mautrix-SERVICENAME/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_mautrix_SERVICENAME_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
To use the bridge, you need to start a chat with `@SERVICENAMEbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
For details about the next steps, refer to each bridge's individual documentation page.
Send `help` to the bot to see the available commands.
If you run into trouble, check the [Troubleshooting](#troubleshooting) section below.
### Set up Double Puppeting (optional)
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
To set it up, you have 2 ways of going about it.
#### Method 1: automatically, by enabling Appservice Double Puppet (recommended)
To set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html), you could enable the [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service for this playbook.
Appservice Double Puppet is a homeserver appservice through which bridges (and potentially other services) can impersonate any user on the homeserver.
To enable the Appservice Double Puppet service, add the following configuration to your `vars.yml` file:
```yaml
matrix_appservice_double_puppet_enabled:true
```
When enabled, double puppeting will automatically be enabled for all bridges that support double puppeting via the appservice method.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
**Notes**:
- Previously there were multiple different automatic double puppeting methods like one with the help of the [Shared Secret Auth password provider module](./configuring-playbook-shared-secret-auth.md), but they have been superseded by this Appservice Double Puppet method. Double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future as the older methods were completely removed in the megabridge rewrites on [the upstream project](https://docs.mau.fi/bridges/general/double-puppeting.html#automatically).
<!-- TODO: remove this note if the Shared Secret Auth service has stopped working or the bridges have been removed -->
- Some bridges like [the deprecated Facebook mautrix bridge](configuring-playbook-bridge-mautrix-facebook.md) and [matrix-appservice-kakaotalk](configuring-playbook-bridge-appservice-kakaotalk.md), which is partially based on the Facebook bridge, are compatible with the Shared Secret Auth service only. These bridges automatically perform Double Puppeting if [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the session for which you obtained an access token some time in the future, as that would break the Double Puppeting feature
## Troubleshooting
For troubleshooting information with a specific bridge, please see the playbook documentation about it (some other document in in `docs/`) and the upstream ([mautrix](https://github.com/mautrix)) bridge documentation for that specific bridge.
If the bridge's bot doesn't accept the invite to a chat, refer [the official troubleshooting page](https://docs.mau.fi/bridges/general/troubleshooting.html) as well.
If you found bugs in mautrix bridges, they should be reported to the upstream project, in the corresponding mautrix repository, not to us.
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) and [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md) bridges supported by the playbook.
- For using as a Bot we recommend the [Appservice Discord](configuring-playbook-bridge-appservice-discord.md), because it supports plumbing.
- For personal use with a discord account we recommend the `mautrix-discord` bridge (the one being discussed here), because it is the most fully-featured and stable of the 3 Discord bridges supported by the playbook.
@ -18,7 +32,9 @@ If this is a dealbreaker for you, consider using one of the other Discord bridge
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
@ -28,16 +44,12 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_discord_enabled:true
```
You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
### Additional configuration
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-mautrix-discord/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-mautrix-discord/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_mautrix_discord_configuration_extension_yaml` variable
<!-- NOTE: common 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
@ -45,64 +57,38 @@ 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
### Logging in
To use the bridge, you need to start a chat with `@discordbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
#### Method 1: Login using QR code (recommended)
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/discord/authentication.html).
For using this bridge, you would need to authenticate by **scanning a QR code** with the Discord app on your phone.
After logging in, the bridge will create portal rooms for some recent direct messages.
You can delete the Discord app after the authentication process.
### Bridge guilds
#### Method 2: Login using Discord token (not recommended)
If you'd like to bridge guilds, send `guilds status` to see the list of guilds, then send `guilds bridge GUILD_ID_HERE` for each guild that you'd like bridged. Make sure to replace `GUILD_ID_HERE` with the guild's ID.
To acquire the token, open Discord in a private browser window. Then open the developer settings (keyboard shortcut might be "ctrl+shift+i" or by pressing "F12"). Navigate to the "Network" tab then reload the page. In the URL filter or search bar type "/api" and find the response with the file name of "library". Under the request headers you should find a variable called "Authorization", this is the token to your Discord account. After copying the token, you can close the browser window.
After bridging, spaces will be created automatically, and rooms will be created if necessary when messages are received. You can also pass `--entire` to the bridge command to immediately create all rooms.
### Bridging
If you want to manually bridge channels, invite the bot to the room you want to bridge, and run `!discord bridge CHANNEL_ID_HERE` to bridge the room. Make sure to replace `CHANNEL_ID_HERE` with the channel's ID.
1. Start a chat with `@discordbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
2. If you would like to login to Discord using a token, send `login-token` command, otherwise, send `login-qr` command.
3. You'll see a QR code which you need to scan with the Discord app on your phone. You can scan it with the camera app too, which will open Discord, which will then instruct you to scan it a 2nd time in the Discord app.
4. After confirming (in the Discord app) that you'd like to allow this login, the bot should respond with "Succcessfully authenticated as …"
5. Now that you're logged in, you can send `help` to the bot to see the available commands.
6. Some Direct Messages from Discord should start syncing automatically
7. If you'd like to bridge guilds:
- send `guilds status` to see the list of guilds
- for each guild that you'd like bridged, send `guilds bridge GUILD_ID --entire`
8. You may wish to uninstall the Discord app from your phone now. It's not needed for the bridge to function.
## Troubleshooting
### 💡 Set up Double Puppeting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-discord`.
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
### Increase logging verbosity
To set it up, you have 2 ways of going about it.
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:
#### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Discord` device some time in the future, as that would break the Double Puppeting feature
# Setting up Mautrix Facebook bridging (optional, deprecated)
**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.
<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.
The playbook can install and configure [mautrix-facebook](https://github.com/mautrix/facebook) for you.
See the project's [documentation](https://github.com/mautrix/facebook/blob/master/ROADMAP.md) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/mautrix/facebook/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisite (optional)
### Enable Shared Secret Auth
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
@ -20,40 +38,11 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_facebook_enabled:true
```
There are some additional things you may wish to configure about the bridge before you continue.
### Extending the configuration
Encryption support is off by default. If you would like to enable encryption, add the following to your `vars.yml` file:
There are some additional things you may wish to configure about the bridge.
You may wish to look at `roles/custom/matrix-bridge-mautrix-facebook/templates/config.yaml.j2` and `roles/custom/matrix-bridge-mautrix-facebook/defaults/main.yml` to find other things you would like to configure.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -61,49 +50,33 @@ 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
To use the bridge, you need to start a chat with `@facebookbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `login YOUR_FACEBOOK_EMAIL_ADDRESS` to the bridge bot to enable bridging for your Facebook Messenger account. You can learn more here about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/facebook/authentication.html).
You then need to send `login YOUR_FACEBOOK_EMAIL_ADDRESS` to the bridge bot to enable bridging for your Facebook Messenger account.
If you run into trouble, check the [Troubleshooting](#troubleshooting) section below.
### 💡 Set up Double Puppeting
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
To set it up, you have 2 ways of going about it.
#### Method 1: automatically, by enabling Shared Secret Auth
The bridge automatically performs Double Puppeting if [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Facebook` device some time in the future, as that would break the Double Puppeting feature
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-facebook`.
### Increase logging verbosity
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
```yaml
matrix_mautrix_facebook_logging_level:DEBUG
```
### Facebook rejecting login attempts and forcing you to change password
If your Matrix server is in a wildly different location than where you usually use your Facebook account from, the bridge's login attempts may be outright rejected by Facebook. Along with that, Facebook may even force you to change the account's password.
# 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>
The playbook can install and configure [mautrix-gmessages](https://github.com/mautrix/gmessages) for you, for bridging to [Google Messages](https://messages.google.com/).
See the project's [documentation](https://docs.mau.fi/bridges/go/gmessages/index.html) 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) for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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
@ -18,45 +30,43 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_gmessages_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`
- 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
To use the bridge, you need to start a chat with `@gmessagesbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
### 💡 Set up Double Puppeting
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/gmessages/authentication.html).
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
After logging in, the bridge will create portal rooms for recent chats.
To set it up, you have 2 ways of going about it.
## Troubleshooting
#### Method 1: automatically, by enabling Appservice Double Puppet
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-gmessages`.
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service is configured and enabled on the server for this playbook.
### Increase logging verbosity
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
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:
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-gmessages` device some time in the future, as that would break the Double Puppeting feature
# 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>
The playbook can install and configure [mautrix-googlechat](https://github.com/mautrix/googlechat) for you.
See the project's [documentation](https://docs.mau.fi/bridges/python/googlechat/index.html) to learn what it does and why it might be useful to you.
## Prerequisite (optional)
### Enable Appservice Double Puppet or Shared Secret Auth
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
@ -18,55 +33,42 @@ To enable the [Google Chat](https://chat.google.com/) bridge, add the following
matrix_mautrix_googlechat_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`
- 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
To use the bridge, you need to start a chat with `googlechat bridge bot` with handle `@googlechatbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
To use the bridge, you need to start a chat with `@googlechatbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `login` to the bridge bot to receive a link to the portal from which you can enable the bridging. Open the link sent by the bot and follow the instructions.
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/googlechat/authentication.html).
Automatic login may not work. If it does not, reload the page and select the "Manual login" checkbox before starting. Manual login involves logging into your Google account normally and then manually getting the OAuth token from browser cookies with developer tools.
After logging in, the bridge will create portal rooms for recent chats. Portal rooms for other chats will be created as you receive messages.
Once logged in, recent chats should show up as new conversations automatically. Other chats will get portals as you receive messages.
## Troubleshooting
You can learn more about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/googlechat/authentication.html).
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-googlechat`.
### 💡 Set up Double Puppeting
### Increase logging verbosity
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
To set it up, you have 2 ways of going about it.
#### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-googlechat` device some time in the future, as that would break the Double Puppeting feature
💡 **Note**: This bridge has been deprecated in favor of [Google Chat bridge](https://github.com/mautrix/googlechat), which can be installed using [this playbook](configuring-playbook-bridge-mautrix-googlechat.md). Installing the mautrix-hangouts bridge is **no longer possible**. For now, this documentation page remains here for historical purposes.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
The playbook can install and configure [mautrix-hangouts](https://github.com/mautrix/hangouts) for you.
# Setting up Mautrix Hangouts bridging (optional, removed)
See the project's [documentation](https://docs.mau.fi/bridges/python/hangouts/index.html) to learn what it does and why it might be useful to you.
🪦 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.
## Prerequisite (optional)
You may wish to use the [Google Chat bridge](https://github.com/mautrix/googlechat) instead.
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
## Uninstalling the bridge manually
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
If you still have the Hangouts bridge installed on your Matrix server, the playbook can no longer help you uninstall it and you will need to do it manually. To uninstall manually, run these commands on the server:
## Adjusting the playbook configuration
To enable the [Google Hangouts](https://hangouts.google.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
matrix_mautrix_hangouts_enabled:true
```
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
- The `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
## Usage
To use the bridge, you need to start a chat with `Hangouts bridge bot` with handle `@hangoutsbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `login` to the bridge bot to receive a link to the portal from which you can enable the bridging. Open the link sent by the bot and follow the instructions.
Automatic login may not work. If it does not, reload the page and select the "Manual login" checkbox before starting. Manual login involves logging into your Google account normally and then manually getting the OAuth token from browser cookies with developer tools.
Once logged in, recent chats should show up as new conversations automatically. Other chats will get portals as you receive messages.
You can learn more about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/hangouts/authentication.html).
### 💡 Set up Double Puppeting
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
To set it up, you have 2 ways of going about it.
#### Method 1: automatically, by enabling Shared Secret Auth
The bridge automatically performs Double Puppeting if [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Hangouts` device some time in the future, as that would break the Double Puppeting feature
# Setting up Mautrix Instagram bridging (optional, deprecated)
**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.
<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.
The playbook can install and configure [mautrix-instagram](https://github.com/mautrix/instagram) for you.
See the project's [documentation](https://docs.mau.fi/bridges/python/instagram/index.html) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/mautrix/instagram/blob/master/README.md) to learn what it does and why it might be useful to you.
## Adjusting the playbook configuration
@ -14,33 +25,11 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_instagram_enabled:true
```
There are some additional things you may wish to configure about the bridge before you continue.
### Extending the configuration
Encryption support is off by default. If you would like to enable encryption, add the following to your `vars.yml` file:
There are some additional things you may wish to configure about the bridge.
You may wish to look at `roles/custom/matrix-bridge-mautrix-instagram/templates/config.yaml.j2` and `roles/custom/matrix-bridge-mautrix-instagram/defaults/main.yml` to find other things you would like to configure.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -48,21 +37,27 @@ 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
To use the bridge, you need to start a chat with `@instagrambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `login YOUR_INSTAGRAM_EMAIL_ADDRESS YOUR_INSTAGRAM_PASSWORD` to the bridge bot to enable bridging for your instagram/Messenger account.
You then need to send `login YOUR_INSTAGRAM_EMAIL_ADDRESS YOUR_INSTAGRAM_PASSWORD` to the bridge bot to enable bridging for your instagram/Messenger account.
You can learn more here about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/instagram/authentication.html).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-instagram`.
### Increase logging verbosity
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
# 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>
The playbook can install and configure the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge for you.
See the project's [documentation](https://docs.mau.fi/bridges/go/meta/index.html) to learn what it does and why it might be useful to you.
Since this bridge component can bridge to both [Messenger](https://messenger.com/) and [Instagram](https://instagram.com/) and you may wish to do both at the same time, the playbook makes it available via 2 different Ansible roles (`matrix-bridge-mautrix-meta-messenger` and `matrix-bridge-mautrix-meta-instagram`). The latter is a reconfigured copy of the first one (created by `just rebuild-mautrix-meta-instagram` and `bin/rebuild-mautrix-meta-instagram.sh`).
This documentation page only deals with the bridge's ability to bridge to Instagram. For bridging to Facebook/Messenger, see [Setting up Messenger bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-messenger.md).
@ -23,7 +34,7 @@ Then, consider disabling the old bridge in your configuration, so it won't recre
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.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -73,39 +58,30 @@ 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
To use the bridge, you need to start a chat with `@instagrambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
### 💡 Set up Double Puppeting
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/meta/authentication.html).
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
After logging in, the bridge will sync recent chats.
To set it up, you have 2 ways of going about it.
## Troubleshooting
#### Method 1: automatically, by enabling Appservice Double Puppet
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-meta-instagram`.
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service is configured and enabled on the server for this playbook.
### Increase logging verbosity
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
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:
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the session for which you obtained an access token some time in the future, as that would break the Double Puppeting feature
```yaml
# This bridge uses zerolog, so valid levels are: panic, fatal, error, warn, info, debug, trace
# 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>
The playbook can install and configure the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge for you.
See the project's [documentation](https://docs.mau.fi/bridges/go/meta/index.html) to learn what it does and why it might be useful to you.
Since this bridge component can bridge to both [Messenger](https://messenger.com/) and [Instagram](https://instagram.com/) and you may wish to do both at the same time, the playbook makes it available via 2 different Ansible roles (`matrix-bridge-mautrix-meta-messenger` and `matrix-bridge-mautrix-meta-instagram`). The latter is a reconfigured copy of the first one (created by `just rebuild-mautrix-meta-instagram` and `bin/rebuild-mautrix-meta-instagram.sh`).
This documentation page only deals with the bridge's ability to bridge to Facebook Messenger. For bridging to Instagram, see [Setting up Instagram bridging via Mautrix Meta](configuring-playbook-bridge-mautrix-meta-instagram.md).
@ -22,7 +34,7 @@ Then, consider disabling the old bridge in your configuration, so it won't recre
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.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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
@ -41,44 +53,18 @@ As mentioned above, the [mautrix-meta](https://github.com/mautrix/meta) bridge s
The bridge can pull your Messenger messages via 3 different methods:
- (`facebook`) Facebook via `facebook.com`
- (`facebook-tor`) Facebook via `facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion` ([Tor](https://www.torproject.org/)) - does not currently proxy media downloads
- (default) (`messenger`) Messenger via `messenger.com`- usable even without a Facebook account
- (`facebook-tor`) Facebook via `facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion` ([Tor](https://www.torproject.org/)) — does not currently proxy media downloads
- (default) (`messenger`) Messenger via `messenger.com`— usable even without a Facebook account
You may switch the mode via the `matrix_mautrix_meta_messenger_meta_mode` variable. The playbook defaults to the `messenger` mode, because it's most universal (every Facebook user has a Messenger account, but the opposite is not true).
Note that switching the mode (especially between `facebook*` and `messenger`) will intentionally make the bridge use another database (`matrix_mautrix_meta_facebook` or `matrix_mautrix_meta_messenger`) to isolate the 2 instances. Switching between Tor and non-Tor may be possible without dataloss, but your mileage may vary. Before switching to a new mode, you may wish to de-configure the old one (send `help` to the bridge bot and unbridge your portals, etc.).
### Bridge permissions
### Extending the configuration
By default, any user on your homeserver will be able to use the bridge.
There are some additional things you may wish to configure about the bridge.
Different levels of permission can be granted to users:
-`relay` - Allowed to be relayed through the bridge, no access to commands
-`user` - Use the bridge with puppeting
-`admin` - Use and administer the bridge
The permissions are following the sequence: nothing <`relay`<`user`<`admin`.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -86,43 +72,32 @@ 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
To use the bridge, you need to start a chat with `@messengerbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain). Note that the user ID of the bridge's bot is not `@facebookbot:example.com`.
You then need to send a `login` command and follow the bridge bot's instructions.
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/meta/authentication.html).
Given that the bot is configured in `messenger` [bridge mode](#bridge-mode) by default, you will need to log in to [messenger.com](https://messenger.com/) (not `facebook.com`!) and obtain the cookies from there as per [the bridge's authentication instructions](https://docs.mau.fi/bridges/go/meta/authentication.html).
After logging in, the bridge will sync recent chats.
### 💡 Set up Double Puppeting
**Note**: given that the bot is configured in `messenger` [bridge mode](#bridge-mode) by default, you will need to log in to [messenger.com](https://messenger.com/) (not `facebook.com`!) and obtain the cookies from there.
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
## Troubleshooting
To set it up, you have 2 ways of going about it.
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-meta-messenger`.
#### Method 1: automatically, by enabling Appservice Double Puppet
### Increase logging verbosity
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service is configured and enabled on the server for this playbook.
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:
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the session for which you obtained an access token some time in the future, as that would break the Double Puppeting feature
```yaml
# This bridge uses zerolog, so valid levels are: panic, fatal, error, warn, info, debug, trace
<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-signal](https://github.com/mautrix/signal) for you.
See the project's [documentation](https://docs.mau.fi/bridges/python/signal/index.html) to learn what it does and why it might be useful to you.
**Note**: This revamped version of the [mautrix-signal (legacy)](configuring-playbook-bridge-mautrix-signal.md) may increase the CPU usage of your homeserver.
See the project's [documentation](https://docs.mau.fi/bridges/go/signal/index.html) to learn what it does and why it might be useful to you.
## Prerequisites (optional)
@ -18,7 +34,7 @@ However, if you're [using an external Postgres server](configuring-playbook-exte
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.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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
@ -28,46 +44,11 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_signal_enabled:true
```
There are some additional things you may wish to configure about the bridge before you continue.
### Extending the configuration
By default, any user on your homeserver will be able to use the bridge.
There are some additional things you may wish to configure about the bridge.
Different levels of permission can be granted to users:
* relay - Allowed to be relayed through the bridge, no access to commands;
* user - Use the bridge with puppeting;
* admin - Use and administer the bridge.
The permissions are following the sequence: nothing <relay<user<admin.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -75,39 +56,32 @@ 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
To use the bridge, you need to start a chat with `@signalbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
### 💡 Set up Double Puppeting
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/signal/authentication.html).
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
After logging in, the bridge will bridge chats as you receive messages.
To set it up, you have 2 ways of going about it.
**Note**: Signal does not support any kind of message history (even on official apps), so the bridge won't backfill any messages.
#### Method 1: automatically, by enabling Appservice Double Puppet
## Troubleshooting
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service is configured and enabled on the server for this playbook.
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-signal`.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Increase logging verbosity
#### Method 2: manually, by asking each user to provide a working access token
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:
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Signal` device some time in the future, as that would break the Double Puppeting feature
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**Note**: bridging to [Slack](https://slack.com/) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) and [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) bridges supported by the playbook.
- For using as a Bot we recommend the [Appservice Slack](configuring-playbook-bridge-appservice-slack.md), because it supports plumbing. Note that it is not available for new installation unless you have already created a classic Slack application, because the creation of classic Slack applications, which this bridge makes use of, has been discontinued.
- For personal use with a slack account we recommend the `mautrix-slack` bridge (the one being discussed here), because it is the most fully-featured and stable of the 3 Slack bridges supported by the playbook.
@ -20,7 +31,7 @@ Note that neither of these methods are officially supported by Slack. [matrix-ap
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.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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
@ -30,16 +41,12 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_slack_enabled:true
```
You may optionally wish to add some [Additional configuration](#additional-configuration), or to [prepare for double-puppeting](#set-up-double-puppeting) before the initial installation.
### Extending the configuration
### Additional configuration
There are some additional things you may wish to configure about the bridge.
There are some additional options you may wish to configure with the bridge.
Take a look at:
-`roles/custom/matrix-bridge-mautrix-slack/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-mautrix-slack/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_mautrix_slack_configuration_extension_yaml` variable
<!-- 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
@ -47,43 +54,30 @@ 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
1. Start a chat with `@slackbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
2. If you would like to login to Slack using a token, send the `login-token` command, otherwise, send the `login-password` command. Read [here](https://docs.mau.fi/bridges/go/slack/authentication.html) on how to retrieve your token and cookie token.
3. The bot should respond with "Successfully logged into <email> for team <workspace>"
4. Now that you're logged in, you can send `help` to the bot to see the available commands.
5. Slack channels should automatically begin bridging if you authenticated using a token. Otherwise, you must wait to receive a message in the channel if you used password authentication.
To use the bridge, you need to start a chat with `@slackbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
### 💡 Set up Double Puppeting
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/slack/authentication.html).
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
If you authenticated using a token, the recent chats will be bridged automatically (depending on the `conversation_count` setting). Otherwise (i.e. logging with the Discord application), the chats the bot is in will be bridged automatically.
To set it up, you have 2 ways of going about it.
## Troubleshooting
#### Method 1: automatically, by enabling Appservice Double Puppet
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-slack`.
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service is configured and enabled on the server for this playbook.
### Increase logging verbosity
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
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:
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Slack` device some time in the future, as that would break the Double Puppeting feature
<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-telegram](https://github.com/mautrix/telegram) for you.
See the project's [documentation](https://docs.mau.fi/bridges/python/telegram/index.html) to learn what it does and why it might be useful to you.
## Prerequisite (optional)
## Prerequisites
### Obtain a Telegram API key
To use the bridge, you'd need to obtain an API key from [https://my.telegram.org/apps](https://my.telegram.org/apps).
### Enable Appservice Double Puppet or Shared Secret Auth (optional)
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) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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.
**Notes**:
- Double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
- If you decided to enable Double Puppeting manually, send `login-matrix` to the bot in order to receive an instruction about how to send an access token to it.
## Adjusting the playbook configuration
You'll need to obtain API keys from [https://my.telegram.org/apps](https://my.telegram.org/apps) and then add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `YOUR_TELEGRAM_APP_ID` and `YOUR_TELEGRAM_API_HASH`.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
### Enable relay-bot (optional)
<!-- 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.
## Usage
To use the bridge, you need to start a chat with `@telegrambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
If you want to use the relay-bot feature ([relay bot documentation](https://docs.mau.fi/bridges/python/telegram/relay-bot.html)), which allows anonymous user to chat with telegram users, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
If you want to use the relay-bot feature ([relay bot documentation](https://docs.mau.fi/bridges/python/telegram/relay-bot.html)), which allows anonymous user to chat with telegram users, add the following configuration to your `vars.yml` file:
You might also want to give permissions to a user to administrate the bot. See [this section](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional) on the common guide for details about it.
More details about permissions in this example: https://github.com/mautrix/telegram/blob/master/mautrix_telegram/example-config.yaml#L410
If you like to exclude all groups from syncing and use the Telgeram-Bridge only for direct chats, you can add the following additional playbook configuration:
### Use the bridge for direct chats only (optional)
If you want to exclude all groups from syncing and use the Telegram-Bridge only for direct chats, add the following configuration to your `vars.yml` file:
```yaml
matrix_mautrix_telegram_filter_mode:whitelist
```
### 💡 Set up Double Puppeting
### Extending the configuration
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
There are some additional things you may wish to configure about the bridge.
To set it up, you have 2 ways of going about it.
<!-- NOTE: common 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.
#### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
## Installing
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
#### Method 2: manually, by asking each user to provide a working access token
`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.
**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging.
## Usage
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
To use the bridge, you need to start a chat with `@telegrambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/telegram/authentication.html).
- send `login-matrix` to the bot and follow instructions about how to send the access token to it
After logging in, the bridge will create portal rooms for all of your Telegram groups and invite you to them. Note that the bridge won't automatically create rooms for private chats.
- make sure you don't log out the `Mautrix-Telegram` device some time in the future, as that would break the Double Puppeting feature
## 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-telegram`.
### Increase logging verbosity
The default logging level for this component is `WARNING`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**Note**: bridging to [Twitter](https://twitter.com/) can also happen via the [mx-puppet-twitter](configuring-playbook-bridge-mx-puppet-twitter.md) bridge supported by the playbook.
The playbook can install and configure [mautrix-twitter](https://github.com/mautrix/twitter) for you.
@ -8,11 +19,11 @@ See the project's [documentation](https://github.com/mautrix/twitter/blob/master
## Prerequisite (optional)
### Enable Appservice Double Puppet (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.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
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
@ -22,48 +33,43 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_twitter_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`
- 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
1. You then need to start a chat with `@twitterbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
2. Send login-cookie to start the login. The bot should respond with instructions on how to proceed.
To use the bridge, you need to start a chat with `@twitterbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
You can learn more here about authentication from the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/python/twitter/authentication.html).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/twitter/authentication.html).
### 💡 Set up Double Puppeting
After logging in, the bridge will create portal rooms for recent chats. Portal rooms for other chats will be created as you receive messages.
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
## Troubleshooting
To set it up, you have 2 ways of going about it.
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-twitter`.
#### Method 1: automatically, by enabling Appservice Double Puppet
### Increase logging verbosity
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) service is configured and enabled on the server for this playbook.
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:
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Slack` device some time in the future, as that would break the Double Puppeting feature
<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-whatsapp](https://github.com/mautrix/whatsapp) for you.
See the project's [documentation](https://docs.mau.fi/bridges/go/whatsapp/index.html) to learn what it does and why it might be useful to you.
## Prerequisite (optional)
### Enable Appservice Double Puppet or Shared Secret Auth
If you want to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do) for this bridge automatically, you need to have enabled [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service for this playbook.
For details about configuring Double Puppeting for this bridge, see the section below: [Set up Double Puppeting](#-set-up-double-puppeting)
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
@ -18,21 +37,11 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_mautrix_whatsapp_enabled:true
```
Whatsapp multidevice beta is required, now it is enough if Whatsapp is connected to the Internet every 2 weeks.
### Extending the configuration
Therelay bot functionality is off by default. If you would like to enable the relay bot, add the following to your `vars.yml` file:
There are some additional things you may wish to configure about the bridge.
```yaml
matrix_mautrix_whatsapp_bridge_relay_enabled:true
```
By default, only admins are allowed to set themselves as relay users. To allow anyone on your homeserver to set themselves as relay users add this to your `vars.yml` file:
If you want to activate the relay bot in a room, send `!wa set-relay`. To deactivate, send `!wa unset-relay`.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -40,41 +49,32 @@ 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
To use the bridge, you need to start a chat with `@whatsappbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
### 💡 Set up Double Puppeting
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/whatsapp/authentication.html).
After successfully enabling bridging, you may wish to set up [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do).
Approximately in a minute after logging in, the bridge will create portal rooms for recent chats.
To set it up, you have 2 ways of going about it.
**Note**: your linked devices will be logged out if you don’t use your phone for over 14 days (see the official FAQ entry [here](https://faq.whatsapp.com/general/download-and-installation/about-linked-devices)). The bridge will warn you if it doesn't receive any data from the phone over 12 days.
#### Method 1: automatically, by enabling Appservice Double Puppet or Shared Secret Auth
## Troubleshooting
The bridge automatically performs Double Puppeting if [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) or [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service is configured and enabled on the server for this playbook.
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-whatsapp`.
Enabling [Appservice Double Puppet](configuring-playbook-appservice-double-puppet.md) is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Increase logging verbosity
Enabling double puppeting by enabling the [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) service works at the time of writing, but is deprecated and will stop working in the future.
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:
#### Method 2: manually, by asking each user to provide a working access token
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. Refer to the documentation on [how to obtain one](obtaining-access-tokens.md).
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
- make sure you don't log out the `Mautrix-Whatsapp` device some time in the future, as that would break the Double Puppeting feature
# 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>
The playbook can install and configure [mautrix-wsproxy](https://github.com/mautrix/wsproxy) for you.
See the project's [documentation](https://github.com/mautrix/wsproxy/blob/master/README.md) to learn what it does and why it might be useful to you.
## Adjusting DNS records
By default, this playbook installs wsproxy on the `wsproxy.` subdomain (`wsproxy.example.com`) and requires you to create a CNAME record for `wsproxy`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -20,24 +36,24 @@ matrix_mautrix_wsproxy_syncproxy_shared_secret: 'secret token from bridge'
Note that the tokens must match what is compiled into the [mautrix-imessage](https://github.com/mautrix/imessage) bridge running on your Mac or Android device.
### Adjusting the wsproxy URL
By default, this playbook installs wsproxy on the `wsproxy.` subdomain (`wsproxy.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
### Adjusting the wsproxy URL (optional)
By tweaking the `matrix_mautrix_wsproxy_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Change the default hostname
matrix_mautrix_wsproxy_hostname:ws.example.com
```
## Adjusting DNS records
After changing the domain, **you may need to adjust your DNS** records to point the wsproxy domain to the Matrix server.
Once you've decided on the domain, **you may need to adjust your DNS** records to point the wsproxy domain to the Matrix server.
### Extending the configuration
By default, you will need to create a CNAME record for `wsproxy`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
@ -45,17 +61,17 @@ 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 [matrix-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).
## 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-wsproxy`.
# 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.
- For using as a Bot we recommend the [Appservice Discord](configuring-playbook-bridge-appservice-discord.md), because it supports plumbing.
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md)and [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridges supported by the playbook.
- For using as a Bot we recommend the [Appservice Discord](configuring-playbook-bridge-appservice-discord.md), because it supports plumbing.
- For personal use with a discord account we recommend the [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridge, because it is the most fully-featured and stable of the 3 Discord bridges supported by the playbook.
The playbook can install and configure [mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord) for you.
@ -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.
🪦 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.
Bridging to [Skype](https://www.skype.com/) can also happen via the [go-skype-bridge](configuring-playbook-bridge-go-skype-bridge.md) bridge supported by the playbook.
**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.
**Note**: email bridging can also happen via the [email2matrix](configuring-playbook-email2matrix.md) bridge supported by the playbook.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
# Setting up Postmoogle email bridging (optional)
The playbook can install and configure [Postmoogle](https://github.com/etkecc/postmoogle) for you.
@ -19,6 +26,19 @@ If you don't open these ports, you will still be able to send emails, but not re
These port numbers are configurable via the `matrix_postmoogle_smtp_host_bind_port` and `matrix_postmoogle_submission_host_bind_port` variables, but other email servers will try to deliver on these default (standard) ports, so changing them is of little use.
## Adjusting DNS records
To make Postmoogle enable its email sending features, you need to configure MX and TXT (SPF, DMARC, and DKIM) records. See the table below for values which need to be specified.
| Type | Host | Priority | Weight | Port | Target |
You will also need to add several DNS records so that Postmoogle can send emails. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-postmoogle/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
## Installing
@ -75,11 +99,13 @@ Send `!pm help` to the bot in the room to see the available commands.
You can also refer to the upstream [documentation](https://github.com/etkecc/postmoogle).
### Debug/Logs
## Troubleshooting
As with all other services, you can find their logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by running something like`journalctl -fu matrix-postmoogle`
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-postmoogle`.
The default logging level for this bridge is `INFO`, but you can increase it to `DEBUG` with the following additional configuration:
### Increase logging verbosity
The default logging level for this component is `INFO`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
The playbook can install and configure the [matrix-wechat](https://github.com/duo/matrix-wechat) bridge for you (for bridging to the [WeChat](https://www.wechat.com/) network).
The playbook can install and configure [matrix-wechat](https://github.com/duo/matrix-wechat) for you, for bridging to [WeChat](https://www.wechat.com/).
See the project's [documentation](https://github.com/duo/matrix-wechat/blob/master/README.md) to learn what it does and why it might be useful to you.
> [!WARNING]
> This bridge does not work against newer versions of Synapse anymore. See [this issue](https://github.com/duo/matrix-wechat/issues/33). Don't even bother installing it. Unless bridge maintenance is resumed and fixes this issue, we have no choice but to remove it from the playbook.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -12,25 +22,45 @@ To enable the bridge, add the following configuration to your `inventory/host_va
matrix_wechat_enabled:true
```
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-wechat/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-wechat/templates/config.yaml.j2` for the bridge's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_wechat_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 `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
## Usage
Once the bridge is installed, start a chat with `@wechatbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
To use the bridge, you need to start a chat with `@wechatbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
Send `help` to the bot to see the available commands.
## 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-wechat`.
### 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 the [Cactus Comments](https://cactus.chat) system for you.
@ -8,43 +17,45 @@ See the project's [documentation](https://cactus.chat/docs/getting-started/intro
The playbook contains 2 roles for configuring different pieces of the Cactus Comments system:
-`matrix-cactus-comments`- the backend appservice integrating with the Matrix homeserver
-`matrix-cactus-comments`— the backend appservice integrating with the Matrix homeserver
-`matrix-cactus-comments-client`- a static website server serving the [cactus-client](https://cactus.chat/docs/client/introduction/) static assets (`cactus.js` and `styles.css`)
-`matrix-cactus-comments-client`— a static website server serving the [cactus-client](https://cactus.chat/docs/client/introduction/) static assets (`cactus.js` and `styles.css`)
You can enable whichever component you need (typically both).
## Configuration
## Adjusting DNS records (optional)
By default, this playbook installs Cactus Comments' client on the `matrix.` subdomain, at the `/cactus-comments` path (https://matrix.example.com/cactus-comments). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
If you wish to adjust it, see the section [below](#adjusting-the-cactus-comments-client-url-optional) for details about DNS configuration.
## Adjusting the playbook configuration
To enable Cactus Comments, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
#################
## Cactus Comments ##
#################
# This enables the backend (appservice)
matrix_cactus_comments_enabled:true
# This enables client assets static files serving on `https://matrix.example.com/cactus-comments`.
# When the backend (appservice) is enabled, this is also enabled automatically, but we explicitly enable it here.
matrix_cactus_comments_client_enabled:true
# Uncomment and adjust this part if you'd like to use a username different than the default
# matrix_cactus_comments_user_id: "bot.cactusbot"
# To allow guest comments without users needing to log in, you need to have guest registration enabled.
# To do this you need to uncomment one of the following lines (depending if you are using Synapse or Dendrite as a homeserver)
# If you don't know which one you use: The default is Synapse ;)
# matrix_synapse_allow_guest_access: true
# matrix_dendrite_allow_guest_access: true
# This enables client assets static files serving on `https://matrix.example.com/cactus-comments`.
# When the backend (appservice) is enabled, this is also enabled automatically,
# but we explicitly enable it here.
matrix_cactus_comments_client_enabled:true
```
### Adjusting the Cactus Comments' client URL
By default, this playbook installs Cactus Comments' client on the `matrix.` subdomain, at the `/cactus-comments` path (https://matrix.example.com/cactus-comments). This makes it easy to install it, because it **doesn't require additional DNS records to be set up**. If that's okay, you can skip this section.
### Adjusting the Cactus Comments' client URL (optional)
By tweaking the `matrix_cactus_comments_client_hostname` and `matrix_cactus_comments_client_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Change the default hostname and path prefix to host the client assets at a different location
If you've changed the default hostname, you may need to create a CNAME record for the Cactus Comments' client domain (`cactus.example.com`), which targets `matrix.example.com`.
If you've changed the default hostname, **you may need to adjust your DNS** records to point the Cactus Comments' client domain to the Matrix server.
When setting, replace `example.com` with your own.
See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
If you've decided to use the default hostname, you won't need to do any extra DNS configuration.
There are some additional things you may wish to configure about the components.
For `matrix-cactus-comments`, take a look at:
-`roles/custom/matrix-cactus-comments/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
For `matrix-cactus-comments-client`, take a look at:
-`roles/custom/matrix-cactus-comments-client/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
## Installing
@ -67,24 +86,18 @@ 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
Upon starting Cactus Comments, a`bot.cactusbot` user account is created automatically.
To use the component, you need to start a chat with`@bot.cactusbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
To get started, send `help` to the `@bot.cactusbot:example.com` bot to confirm it's working.
Then, register a site by sending `register <YourSiteName>` (where `<YourSiteName>` is a unique identifier you choose. It does not have to match your domain). You will then be invited into a moderation room.
Then, register a site by sending `register YOUR_SITE_NAME_HERE` (where `YOUR_SITE_NAME_HERE` is a unique identifier you choose. It does not have to match your domain). You will then be invited into a moderation room.
Now you are good to go and can embed the comment section on your website!
@ -98,7 +111,7 @@ After including the JavaScript and CSS asset files, insert a `<div>` where you'd
<div id="comment-section"></div>
````
Then, you need to initialize the comment section. Make sure to replace `example.com` with your base domain and `<YourSiteName>` with the one that has been registered above:
Then, you need to initialize the comment section. Make sure to replace `example.com` with your base domain and `YOUR_SITE_NAME_HERE` with the one that has been registered above:
@ -124,3 +137,18 @@ Make sure to replace `example.com` with your base domain before you include the
```
**Note**: if the `matrix_cactus_comments_client_hostname` and `matrix_cactus_comments_client_path_prefix` variables are tweaked, you would need to adjust the URLs of the assets accordingly.
## 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-cactus-comments` for the backend appservice or `journalctl -fu matrix-cactus-comments-client` for the server serving the client assets, respectively.
### Increase logging verbosity
It is possible to increase logging verbosity for `matrix-cactus-comments-client`. The default logging level for this component is `error`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
```yaml
# Controls the SERVER_LOG_LEVEL environment variable.
This playbook can install the [Cinny](https://github.com/ajbura/cinny) Matrix web client for you.
The playbook can install and configure the [Cinny](https://github.com/ajbura/cinny) Matrix web client for you.
Cinny is a web client focusing primarily on simple, elegant and secure interface. It can be installed alongside or instead of [Element Web](./configuring-playbook-client-element-web.md).
@ -8,6 +16,12 @@ Cinny is a web client focusing primarily on simple, elegant and secure interface
- [app.cinny.in](https://app.cinny.in), hosted by the [Cinny](https://cinny.in/) developers
## Adjusting DNS records
By default, this playbook installs Cinny on the `cinny.` subdomain (`cinny.example.com`) and requires you to create a CNAME record for `cinny`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable Cinny, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -16,28 +30,32 @@ To enable Cinny, add the following configuration to your `inventory/host_vars/ma
matrix_client_cinny_enabled:true
```
### Adjusting the Cinny URL
By default, this playbook installs Cinny on the `cinny.` subdomain (`cinny.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
### Adjusting the Cinny URL (optional)
By tweaking the `matrix_client_cinny_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
While a `matrix_client_cinny_path_prefix` variable exists for tweaking the path-prefix, it's [not supported anymore](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3701), because Cinny requires an application rebuild (with a tweaked build config) to be functional under a custom path.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to a different domain (`app.example.com`) than the default one (`cinny.example.com`)
After changing the domain, **you may need to adjust your DNS** records to point the Cinny domain to the Matrix server.
Once you've decided on the domain, **you may need to adjust your DNS** records to point the Cinny domain to the Matrix server.
**Note**: while there is a `matrix_client_cinny_path_prefix` variable for changing the path where Cinny is served, overriding it is [not possible](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3701), because Cinny requires an application rebuild (with a tweaked build config) to be functional under a custom path. You'd need to serve Cinny at a dedicated subdomain.
By default, you will need to create a CNAME record for `cinny`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
If you've adjusted `matrix_client_cinny_hostname`, you will need to adjust your DNS configuration accordingly.
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-client-cinny/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-client-cinny/templates/config.json.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_cinny_configuration_extension_json` variable
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-cinny`.
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.
If you'd like to stop the playbook installing the client, see the section [below](#disabling-element-web) to check the configuration for disabling it.
💡 **Note**: the latest version of Element Web is also available on the web, hosted by 3rd parties. If you trust giving your credentials to the following 3rd party Single Page Applications, you can consider using it from there and avoiding the (small) overhead of self-hosting (by [disabling Element Web](#disabling-element-web)):
- [app.element.io](https://app.element.io/), hosted by [Element](https://element.io/)
- [app.etke.cc](https://app.etke.cc/), hosted by [etke.cc](https://etke.cc/)
## Disabling Element Web
## Adjusting DNS records
If you'd like for the playbook to not install Element Web (or to uninstall it if it was previously installed), add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
By default, this playbook installs Element Web on the `element.` subdomain (`element.example.com`) and requires you to create a CNAME record for `element`, which targets `matrix.example.com`.
```yaml
matrix_client_element_enabled:false
```
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
The playbook provides some customization variables you could use to change Element Web's settings.
### Set the country code for phone number inputs
Their defaults are defined in [`roles/custom/matrix-client-element/defaults/main.yml`](../roles/custom/matrix-client-element/defaults/main.yml) and they ultimately end up in the generated `/matrix/element/config.json` file (on the server). This file is generated from the [`roles/custom/matrix-client-element/templates/config.json.j2`](../roles/custom/matrix-client-element/templates/config.json.j2) template.
You can change the country code (default: `GB`) to use when showing phone number inputs. To change it to `FR` for example, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
**If there's an existing variable** which controls a setting you wish to change, you can simply define that variable in your configuration file (`inventory/host_vars/matrix.example.com/vars.yml`) and [re-run the playbook](installing.md) to apply the changes.
Alternatively, **if there is no pre-defined variable** for an Element Web setting you wish to change:
- you can either **request a variable to be created** (or you can submit such a contribution yourself). Keep in mind that it's **probably not a good idea** to create variables for each one of Element Web's various settings that rarely get used.
- or, you can **extend and override the default configuration** ([`config.json.j2`](../roles/custom/matrix-client-element/templates/config.json.j2)) by making use of the `matrix_client_element_configuration_extension_json_` variable. You can find information about this in [`roles/custom/matrix-client-element/defaults/main.yml`](../roles/custom/matrix-client-element/defaults/main.yml).
- or, if extending the configuration is still not powerful enough for your needs, you can **override the configuration completely** using `matrix_client_element_configuration_default` (or `matrix_client_element_configuration`). You can find information about this in [`roles/custom/matrix-client-element/defaults/main.yml`](../roles/custom/matrix-client-element/defaults/main.yml).
```yaml
matrix_client_element_default_country_code:"FR"
```
### Themes
To change the look of Element Web, you can define your own themes manually by using the `matrix_client_element_setting_defaults_custom_themes` setting.
#### Change the default theme
Or better yet, you can automatically pull it all themes provided by the [aaronraimist/element-themes](https://github.com/aaronraimist/element-themes) project by simply flipping a flag (`matrix_client_element_themes_enabled: true`).
You can change the default theme from `light` to `dark`. To do so, add the following configuration to your `vars.yml` file:
If you make your own theme, we encourage you to submit it to the **aaronraimist/element-themes** project, so that the whole community could easily enjoy it.
```yaml
# Controls the default theme
matrix_client_element_default_theme:'dark'
```
#### Use themes by `element-themes`
You can change the look of Element Web by pulling themes provided by the [aaronraimist/element-themes](https://github.com/aaronraimist/element-themes) project or defining your own themes manually.
To pull the themes and use them for your Element Web instance, add the following configuration to your `vars.yml` file:
```yaml
matrix_client_element_themes_enabled:true
```
If the variable is set to `true`, all themes found in the repository specified with `matrix_client_element_themes_repository_url` will be installed and enabled automatically.
Note that for a custom theme to work well, all Element Web instances that you use must have the same theme installed.
### Adjusting the Element Web URL
#### Define themes manually
By default, this playbook installs Element Web on the `element.` subdomain (`element.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
You can also define your own themes manually by adding and adjusting the following configuration to your `vars.yml` file:
```yaml
# Controls the `setting_defaults.custom_themes` setting of the Element Web configuration.
If you define your own themes with it and set `matrix_client_element_themes_enabled` to `true` for the themes by `element-themes`, your themes will be preserved as well.
If you make your own theme, we encourage you to submit it to the **aaronraimist/element-themes** project, so that the whole community could easily enjoy it.
### Adjusting the Element Web URL (optional)
By tweaking the `matrix_client_element_hostname` and `matrix_client_element_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to the domain used for Matrix services (`matrix.example.com`),
Once you've decided on the domain and path, **you may need to adjust your DNS** records to point the Element Web domain to the Matrix server.
By default, you will need to create a CNAME record for `element`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
After changing the domain, **you may need to adjust your DNS** records to point the Element domain to the Matrix server.
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-client-element/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-client-element/templates/config.json.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_element_configuration_extension_json` variable
For example, to override some Element Web settings, add the following configuration to your `vars.yml` file:
```yaml
# Your custom JSON configuration for Element Web should go to `matrix_client_element_configuration_extension_json`.
# This configuration extends the default starting configuration (`matrix_client_element_configuration_default`).
#
# You can override individual variables from the default configuration, or introduce new ones.
#
# If you need something more special, you can take full control by
If you'd like for the playbook to not install Element Web (or to uninstall it if it was previously installed), add the following configuration to your `vars.yml` file:
```yaml
matrix_client_element_enabled:false
```
## 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:
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-element`.
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`.
This playbook can install the [Hydrogen](https://github.com/element-hq/hydrogen-web) Matrix web client for you.
The playbook can install and configure the [Hydrogen](https://github.com/element-hq/hydrogen-web) Matrix web client for you.
Hydrogen is a lightweight web client that supports mobile and legacy web browsers. It can be installed alongside or instead of Element Web.
## Adjusting DNS records
By default, this playbook installs Hydrogen on the `hydrogen.` subdomain (`hydrogen.example.com`) and requires you to create a CNAME record for `hydrogen`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable Hydrogen, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -12,13 +27,11 @@ To enable Hydrogen, add the following configuration to your `inventory/host_vars
matrix_client_hydrogen_enabled:true
```
### Adjusting the Hydrogen URL
By default, this playbook installs Hydrogen on the `hydrogen.` subdomain (`hydrogen.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
### Adjusting the Hydrogen URL (optional)
By tweaking the `matrix_client_hydrogen_hostname` and `matrix_client_hydrogen_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to the domain used for Matrix services (`matrix.example.com`),
Once you've decided on the domain and path, **you may need to adjust your DNS** records to point the Hydrogen domain to the Matrix server.
By default, you will need to create a CNAME record for `hydrogen`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
After changing the domain, **you may need to adjust your DNS** records to point the Hydrogen domain to the Matrix server.
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
### Extending the configuration
There are some additional things you may wish to configure about the client.
Take a look at:
-`roles/custom/matrix-client-hydrogen/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-client-hydrogen/templates/config.json.j2` for the client's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_hydrogen_configuration_extension_json` variable
## Installing
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
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-hydrogen`.
This playbook can install the [SchildiChat Web](https://github.com/SchildiChat/schildichat-desktop) Matrix client for you.
The playbook can install and configure the [SchildiChat Web](https://github.com/SchildiChat/schildichat-desktop) Matrix client for you.
SchildiChat Web is a feature-rich messenger for Matrix based on Element Web with some extras and tweaks. It can be installed alongside or instead of Element Web.
@ -8,6 +16,12 @@ SchildiChat Web is a feature-rich messenger for Matrix based on Element Web with
- [app.schildi.chat](https://app.schildi.chat/), hosted by the [SchildiChat](https://schildi.chat/) developers
## Adjusting DNS records
By default, this playbook installs SchildiChat Web on the `schildichat.` subdomain (`schildichat.example.com`) and requires you to create a CNAME record for `schildichat`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable SchildiChat Web, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
@ -16,37 +30,57 @@ To enable SchildiChat Web, add the following configuration to your `inventory/ho
matrix_client_schildichat_enabled:true
```
The playbook provides some customization variables you could use to change SchildiChat Web's settings.
### Set the country code for phone number inputs
Their defaults are defined in [`roles/custom/matrix-client-schildichat/defaults/main.yml`](../roles/custom/matrix-client-schildichat/defaults/main.yml) and they ultimately end up in the generated `/matrix/schildichat/config.json` file (on the server). This file is generated from the [`roles/custom/matrix-client-schildichat/templates/config.json.j2`](../roles/custom/matrix-client-schildichat/templates/config.json.j2) template.
You can change the country code (default: `GB`) to use when showing phone number inputs. To change it to `FR` for example, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
**If there's an existing variable** which controls a setting you wish to change, you can simply define that variable in your configuration file (`inventory/host_vars/matrix.example.com/vars.yml`) and [re-run the playbook](installing.md) to apply the changes.
Alternatively, **if there is no pre-defined variable** for a SchildiChat Web setting you wish to change:
- you can either **request a variable to be created** (or you can submit such a contribution yourself). Keep in mind that it's **probably not a good idea** to create variables for each one of SchildiChat Web's various settings that rarely get used.
- or, you can **extend and override the default configuration** ([`config.json.j2`](../roles/custom/matrix-client-schildichat/templates/config.json.j2)) by making use of the `matrix_client_schildichat_configuration_extension_json_` variable. You can find information about this in [`roles/custom/matrix-client-schildichat/defaults/main.yml`](../roles/custom/matrix-client-schildichat/defaults/main.yml).
- or, if extending the configuration is still not powerful enough for your needs, you can **override the configuration completely** using `matrix_client_schildichat_configuration_default` (or `matrix_client_schildichat_configuration`). You can find information about this in [`roles/custom/matrix-client-schildichat/defaults/main.yml`](../roles/custom/matrix-client-schildichat/defaults/main.yml).
To change the look of SchildiChat Web, you can define your own themes manually by using the `matrix_client_schildichat_setting_defaults_custom_themes` setting.
#### Change the default theme
Or better yet, you can automatically pull it all themes provided by the [aaronraimist/element-themes](https://github.com/aaronraimist/element-themes) project by simply flipping a flag (`matrix_client_schildichat_themes_enabled: true`).
You can change the default theme from `light` to `dark`. To do so, add the following configuration to your `vars.yml` file:
If you make your own theme, we encourage you to submit it to the **aaronraimist/element-themes** project, so that the whole community could easily enjoy it.
```yaml
# Controls the default theme
matrix_client_schildichat_default_theme:'dark'
```
#### Use themes by `element-themes`
You can change the look of SchildiChat Web by pulling themes provided by the [aaronraimist/element-themes](https://github.com/aaronraimist/element-themes) project or defining your own themes manually.
To pull the themes and use them for your SchildiChat Web instance, add the following configuration to your `vars.yml` file:
```yaml
matrix_client_schildichat_themes_enabled:true
```
If the variable is set to `true`, all themes found in the repository specified with `matrix_client_schildichat_themes_repository_url` will be installed and enabled automatically.
Note that for a custom theme to work well, all SchildiChat Web instances that you use must have the same theme installed.
### Adjusting the SchildiChat Web URL
#### Define themes manually
By default, this playbook installs SchildiChat Web on the`schildichat.` subdomain (`schildichat.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
You can also define your own themes manually by adding and adjusting the following configuration to your `vars.yml` file:
```yaml
# Controls the `setting_defaults.custom_themes` setting of the SchildiChat Web configuration.
If you define your own themes with it and set `matrix_client_schildichat_themes_enabled` to `true` for the themes by `element-themes`, your themes will be preserved as well.
If you make your own theme, we encourage you to submit it to the **aaronraimist/element-themes** project, so that the whole community could easily enjoy it.
### Adjusting the SchildiChat Web URL (optional)
By tweaking the `matrix_client_schildichat_hostname` and `matrix_client_schildichat_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to the domain used for Matrix services (`matrix.example.com`),
Once you've decided on the domain and path, **you may need to adjust your DNS** records to point the SchildiChat Web domain to the Matrix server.
By default, you will need to create a CNAME record for `schildichat`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
After changing the domain, **you may need to adjust your DNS** records to point the SchildiChat 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.
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-client-schildichat/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-client-schildichat/templates/config.json.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_client_schildichat_configuration_extension_json` variable
For example, to override some SchildiChat Web settings, add the following configuration to your `vars.yml` file:
```yaml
# Your custom JSON configuration for SchildiChat Web should go to `matrix_client_schildichat_configuration_extension_json`.
# This configuration extends the default starting configuration (`matrix_client_schildichat_configuration_default`).
#
# You can override individual variables from the default configuration, or introduce new ones.
#
# If you need something more special, you can take full control by
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
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-schildichat`.
By default, this playbook configures the [Synapse](https://github.com/element-hq/synapse) Matrix server, but you can also use [Conduit](https://conduit.rs).
The playbook can install and configure the [Conduit](https://conduit.rs) Matrix server for you.
**Notes**:
See the project's [documentation](https://docs.conduit.rs/) to learn what it does and why it might be useful to you.
- **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Conduit). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
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.
- **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
💡 **Note**: The playbook also supports installing a (currently) faster-moving Conduit fork called [conduwuit](./configuring-playbook-conduwuit.md).
> [!WARNING]
> - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Conduit). Proceed below only if you're OK with losing data or you're dealing with a server on a new domain name, which hasn't participated in the Matrix federation yet.
> - **Homeserver implementations other than Synapse may not be fully functional**. The playbook may also not assist you in an optimal way (like it does with Synapse). Make yourself familiar with the downsides before proceeding
## Adjusting the playbook configuration
To use Conduit, you **generally** need to add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
To use Conduit, 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:conduit
```
### Extending the configuration
There are some additional things you may wish to configure about the server.
Take a look at:
-`roles/custom/matrix-conduit/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-conduit/templates/conduit.toml.j2` for the server's default configuration
If you'd like to have your own different configuration, feel free to copy and paste the original files into your inventory (e.g. in `inventory/host_vars/matrix.example.com/`) and then change the specific host's `vars.yml` file like this:
Since it is difficult to create the first user account on Conduit (see [famedly/conduit#276](https://gitlab.com/famedly/conduit/-/issues/276) and [famedly/conduit#354](https://gitlab.com/famedly/conduit/-/merge_requests/354)) and it does not support [registering users](registering-users.md) (via the command line or via the playbook) like Synapse and Dendrite do, we recommend the following procedure:
1. Add `matrix_conduit_allow_registration: true` to your `vars.yml` the first time around, temporarily
2. Run the playbook (`ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`- see [Installing](installing.md))
2. Run the playbook (`ansible-playbook -i inventory/hosts setup.yml --tags=setup-all,start`— see [Installing](installing.md))
3. Create your first user via Element Web or any other client which supports creating users
4. Get rid of `matrix_conduit_allow_registration: true` from your `vars.yml`
5. Run the playbook again (`ansible-playbook -i inventory/hosts setup.yml --tags=setup-conduit,start` would be enough this time)
@ -29,9 +55,9 @@ Since it is difficult to create the first user account on Conduit (see [famedly/
## Configuring bridges / appservices
Automatic appservice setup is currently unsupported when using Conduit. After setting up the service as usual you may notice that it is unable to start.
For other homeserver implementations (like Synapse and Dendrite), the playbook automatically registers appservices (for bridges, bots, etc.) with the homeserver.
You will have to manually register appservices using the the [register-appservice](https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.md) command.
For Conduit, you will have to manually register appservices using the the [register-appservice](https://gitlab.com/famedly/conduit/-/blob/next/APPSERVICES.md) command.
Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`, then pass the content to Conduit:
@ -39,6 +65,7 @@ Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/ma
```
as_token: <token>
de.sorunome.msc2409.push_ephemeral: true
receive_ephemeral: true
hs_token: <token>
id: signal
namespaces:
@ -54,3 +81,7 @@ Find the `registration.yaml` in the `/matrix` directory, for example `/matrix/ma
sender_localpart: _bot_signalbot
url: http://matrix-mautrix-signal:29328
```
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-conduit`.
The playbook can install and configure the [conduwuit](https://conduwuit.puppyirl.gay/) Matrix server for you.
See the project's [documentation](https://conduwuit.puppyirl.gay/) 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**: conduwuit is a fork of [Conduit](./configuring-playbook-conduit.md), which the playbook also supports. See [Differences from upstream Conduit](https://conduwuit.puppyirl.gay/differences.html).
> [!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
To use conduwuit, you **generally** need to adjust the `matrix_homeserver_implementation: synapse` configuration on your `inventory/host_vars/matrix.example.com/vars.yml` file as below:
```yaml
matrix_homeserver_implementation:conduwuit
# Registering users can only happen via the API,
# so it makes sense to enable it, at least initially.
matrix_conduwuit_config_allow_registration:true
# Generate a strong registration token to protect the registration endpoint from abuse.
# You can create one with a command like `pwgen -s 64 1`.
matrix_conduwuit_config_registration_token:''
```
### Extending the configuration
There are some additional things you may wish to configure about the server.
Take a look at:
-`roles/custom/matrix-conduwuit/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-conduwuit/templates/conduwuit.toml.j2` for the server's default configuration
There are various Ansible variables that control settings in the `conduwuit.toml` file.
If a specific setting you'd like to change does not have a dedicated Ansible variable, you can either submit a PR to us to add it, or you can [override the setting using an environment variable](https://conduwuit.puppyirl.gay/configuration.html#environment-variables) using `matrix_conduwuit_environment_variables_extension`. For example:
Unlike other homeserver implementations (like Synapse and Dendrite), conduwuit does not support creating users via the command line or via the playbook.
If you followed the instructions above (see [Adjusting the playbook configuration](#adjusting-the-playbook-configuration)), you should have registration enabled and protected by a registration token.
This should allow you to create the first user account via any client (like [Element Web](./configuring-playbook-client-element-web.md)) which supports creating users.
The **first user account that you create will be marked as an admin** and **will be automatically invited to an admin room**.
## Configuring bridges / appservices
For other homeserver implementations (like Synapse and Dendrite), the playbook automatically registers appservices (for bridges, bots, etc.) with the homeserver.
For conduwuit, you will have to manually register appservices using the [`!admin appservices register` command](https://conduwuit.puppyirl.gay/appservices.html#set-up-the-appservice---general-instructions) sent to the server bot account.
The server's bot account has a Matrix ID of `@conduit:example.com` (not `@conduwuit:example.com`!) due to conduwuit's historical legacy.
Your first user account would already have been invited to an admin room with this bot.
Find the appservice file you'd like to register. This can be any `registration.yaml` file found in the `/matrix` directory, for example `/matrix/mautrix-signal/bridge/registration.yaml`.
Then, send its content to the existing admin room:
!admin appservices register
```
as_token: <token>
de.sorunome.msc2409.push_ephemeral: true
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
```
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-conduwuit`.
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`.
By default, this playbook configures the [Synapse](https://github.com/element-hq/synapse) Matrix server, but you can also use [Dendrite](https://github.com/matrix-org/dendrite).
The playbook can install and configure the [Dendrite](https://github.com/element-hq/dendrite) Matrix server for you.
**Notes**:
See the project's [documentation](https://element-hq.github.io/dendrite/) to learn what it does and why it might be useful to you.
- **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Dendrite). 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.
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.
- **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
> [!WARNING]
> - **You can't switch an existing Matrix server's implementation** (e.g. Synapse -> Dendrite). 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 Dendrite, you **generally** need to add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
To use Dendrite, 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:dendrite
```
The playbook provides lots of customization variables you could use to change Dendrite's settings.
### Extending the configuration
Their defaults are defined in [`roles/custom/matrix-dendrite/defaults/main.yml`](../roles/custom/matrix-dendrite/defaults/main.yml) and they ultimately end up in the generated `/matrix/dendrite/config/dendrite.yaml` file (on the server). This file is generated from the [`roles/custom/matrix-dendrite/templates/dendrite/dendrite.yaml.j2`](../roles/custom/matrix-dendrite/templates/dendrite/dendrite.yaml.j2) template.
There are some additional things you may wish to configure about the server.
**If there's an existing variable** which controls a setting you wish to change, you can simply define that variable in your configuration file (`inventory/host_vars/matrix.example.com/vars.yml`) and [re-run the playbook](installing.md) to apply the changes.
Take a look at:
Alternatively, **if there is no pre-defined variable** for a Dendrite setting you wish to change:
-`roles/custom/matrix-dendrite/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-dendrite/templates/dendrite.yaml.j2` for the server's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_dendrite_configuration_extension_yaml` variable
- you can either **request a variable to be created** (or you can submit such a contribution yourself). Keep in mind that it's **probably not a good idea** to create variables for each one of Dendrite's various settings that rarely get used.
For example, to override some Dendrite settings, add the following configuration to your `vars.yml` file:
- or, you can **extend and override the default configuration** ([`dendrite.yaml.j2`](../roles/custom/matrix-dendrite/templates/dendrite/dendrite.yaml.j2)) by making use of the `matrix_dendrite_configuration_extension_yaml` variable. You can find information about this in [`roles/custom/matrix-dendrite/defaults/main.yml`](../roles/custom/matrix-dendrite/defaults/main.yml).
- or, if extending the configuration is still not powerful enough for your needs, you can **override the configuration completely** using `matrix_dendrite_configuration` (or `matrix_dendrite_configuration_yaml`). You can find information about this in [`roles/custom/matrix-dendrite/defaults/main.yml`](../roles/custom/matrix-dendrite/defaults/main.yml).
```yaml
matrix_dendrite_configuration_extension_yaml:|
# Your custom YAML configuration for Dendrite goes here.
# This configuration extends the default starting configuration (`matrix_dendrite_configuration_yaml`).
#
# You can override individual variables from the default configuration, or introduce new ones.
#
# If you need something more special, you can take full control by
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-dendrite`.
### Increase logging verbosity
The default logging level for this component is `warning`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
# Setting up Dimension integration manager (optional, unmaintained)
**[Dimension](https://dimension.t2bot.io) can only be installed after Matrix services are installed and running.** If you're just installing Matrix services for the first time, please continue with the [Configuration](configuring-playbook.md) / [Installation](installing.md) flow and come back here later.
**Notes**:
- Dimension is **[officially unmaintained](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2806#issuecomment-1673559299)**. We recommend not bothering with installing it.
- This playbook now supports running Dimension in both a federated and [unfederated](https://github.com/turt2live/matrix-dimension/blob/master/docs/unfederated.md) environments. This is handled automatically based on the value of `matrix_homeserver_federation_enabled`.
**Note**: Dimension is **[officially unmaintained](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2806#issuecomment-1673559299)**. We recommend not bothering with installing it.
The playbook can install and configure the [Dimension](https://dimension.t2bot.io) integration manager for you.
**Note**: This playbook now supports running [Dimension](https://dimension.t2bot.io) in both a federated and [unfederated](https://github.com/turt2live/matrix-dimension/blob/master/docs/unfederated.md) environments. This is handled automatically based on the value of `matrix_homeserver_federation_enabled`. Enabling Dimension, means that the `openid` API endpoints will be exposed on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. It's something to be aware of, especially in terms of firewall whitelisting (make sure port `8448` is accessible).
See the project's [documentation](https://github.com/turt2live/matrix-dimension/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisites
### Open Matrix Federation port
Enabling the Dimension service will automatically reconfigure your Synapse homeserver to expose the `openid` API endpoints on the Matrix Federation port (usually `8448`), even if [federation](configuring-playbook-federation.md) is disabled. If you enable the component, make sure that the port is accessible.
### Install Matrix services
Dimension can only be installed after Matrix services are installed and running. If you're just installing Matrix services for the first time, please continue with the [Configuration](configuring-playbook.md) / [Installation](installing.md) and come back here later.
### Register a dedicated Matrix user (optional, recommended)
We recommend that you create a dedicated Matrix user for Dimension (`dimension` is a good username).
Generate a strong password for the user. You can create one with a command like `pwgen -s 64 1`.
You can use the playbook to [register a new user](registering-users.md):
Dimension requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
> [!WARNING]
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
## Adjusting DNS records
By default, this playbook installs Dimension on the `dimension.` subdomain (`dimension.example.com`) and requires you to create a CNAME record for `dimension`, which targets `matrix.example.com`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
To enable Dimension, add this to your configuration file (`inventory/host_vars/matrix.example.com/vars.yml`):
To enable Dimension, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
```yaml
matrix_dimension_enabled:true
matrix_dimension_access_token:"ACCESS_TOKEN_HERE"
```
### Define admin users
These users can modify the integrations this Dimension supports. Add this to your configuration file (`inventory/host_vars/matrix.example.com/vars.yml`):
To define admin users who can modify the integrations this Dimension supports, add the following configuration to your `vars.yml` file:
```yaml
matrix_dimension_admins:
@ -26,29 +80,11 @@ matrix_dimension_admins:
The admin interface is accessible within Element Web by accessing it in any room and clicking the cog wheel/settings icon in the top right. Currently, Dimension can be opened in Element Web by the "Add widgets, bridges, & bots" link in the room information.
### Obtain an access token
We recommend that you create a dedicated Matrix user for Dimension (`dimension` is a good username). Follow our [Registering users](registering-users.md) guide to learn how to register **a regular (non-admin) user**.
You are required to specify an access token (belonging to this new user) for Dimension to work. 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.
Add access token to your configuration file (`inventory/host_vars/matrix.example.com/vars.yml`):
For more information on how to acquire an access token, visit [https://t2bot.io/docs/access_tokens](https://t2bot.io/docs/access_tokens).
### Adjusting the Dimension URL
By default, this playbook installs Dimension on the `dimension.` subdomain (`dimension.example.com`) and requires you to [adjust your DNS records](#adjusting-dns-records).
### Adjusting the Dimension URL (optional)
By tweaking the `matrix_dimension_hostname` and `matrix_dimension_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `inventory/host_vars/matrix.example.com/vars.yml` file:
Example additional configuration for your `vars.yml` file:
```yaml
# Switch to the domain used for Matrix services (`matrix.example.com`),
**Note**: While there is a `matrix_dimension_path_prefix` variable for changing the path where Dimension is served, overriding it is not possible due to [this Dimension issue](https://github.com/turt2live/matrix-dimension/issues/510). You must serve Dimension at a dedicated subdomain.
After changing the domain, **you may need to adjust your DNS** records to point the Dimension domain to the Matrix server.
## Adjusting DNS records
If you've decided to reuse the `matrix.` domain, you won't need to do any extra DNS configuration.
Once you've decided on the domain and path, **you may need to adjust your DNS** records to point the Dimension domain to the Matrix server.
**Note**: while there is a `matrix_dimension_path_prefix` variable for changing the path where Dimension is served, overriding it is not possible due to [this Dimension issue](https://github.com/turt2live/matrix-dimension/issues/510). You'd need to serve Dimension at a dedicated subdomain.
By default, you will need to create a CNAME record for `dimension`. See [Configuring DNS](configuring-dns.md) for details about DNS changes.
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-dimension/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-dimension/templates/config.yaml.j2` for the component's default configuration. You can override settings (even those that don't have dedicated playbook variables) using the `matrix_dimension_configuration_extension_yaml` variable
You can find all configuration options on [GitHub page of Dimension project](https://github.com/turt2live/matrix-dimension/blob/master/config/default.yaml).
`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.
- After Dimension has been installed you may need to log out and log back in for it to pick up the new integration manager. Then you can access integrations in Element Web by opening a room, clicking the Room info button (`i`) button in the top right corner of the screen, and then clicking Add widgets, bridges & bots.
## Usage
## Jitsi domain
After Dimension has been installed you may need to log out and log back in for it to pick up the new integration manager. Then you can access integrations in Element Web by opening a room, clicking the room info button (`i`) on the top right corner, and then clicking the "Add widgets, bridges, & bots" link.
By default Dimension will use [jitsi.riot.im](https://jitsi.riot.im/) as the `conferenceDomain` of [Jitsi](https://jitsi.org/) audio/video conference widgets. For users running [a self-hosted Jitsi instance](./configuring-playbook-jitsi.md), you will likely want the widget to use your own Jitsi instance. Currently there is no way to configure this via the playbook, see [this issue](https://github.com/turt2live/matrix-dimension/issues/345) for details.
### Set up a Jitsi widget
In the interim until the above limitation is resolved, an admin user needs to configure the domain via the admin ui once dimension is running. In Element Web, go to *Manage Integrations*→*Settings*→*Widgets*→*Jitsi Conference Settings* and set *Jitsi Domain* and *Jitsi Script URL* appropriately.
By default Dimension will use [jitsi.riot.im](https://jitsi.riot.im/) as the `conferenceDomain` of [Jitsi](https://jitsi.org/) audio/video conference widgets. For users running [a self-hosted Jitsi instance](configuring-playbook-jitsi.md), you will likely want the widget to use your own Jitsi instance.
## Additional features
To set up the widget, an admin user needs to configure the domain via the admin UI once Dimension is running. In Element Web, go to *Manage Integrations* → *Settings* → *Widgets* → *Jitsi Conference Settings* and set *Jitsi Domain* and *Jitsi Script URL* appropriately.
To use a more custom configuration, you can define a `matrix_dimension_configuration_extension_yaml` string variable and put your configuration in it. To learn more about how to do this, refer to the information about `matrix_dimension_configuration_extension_yaml` in the [default variables file](../roles/custom/matrix-dimension/defaults/main.yml) of the Dimension component.
There is unfortunately no way to configure the widget via the playbook. See [this issue](https://github.com/turt2live/matrix-dimension/issues/345) for details.
You can find all configuration options on [GitHub page of Dimension project](https://github.com/turt2live/matrix-dimension/blob/master/config/default.yaml).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-dimension`.
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.
Take a look at:
-`roles/custom/matrix-dynamic-dns/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:
@ -41,3 +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`. 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).
## Relaying email through another SMTP server
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.
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):
## Adjusting the playbook configuration
### Enable DKIM authentication to improve deliverability (optional)
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.
### Configuations for 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/), the free tier allows for up to 100 emails per day to be sent. In the settings below you can provide any email for `exim_relay_sender_address`.
## Installing
The only other thing you need to change is the `exim_relay_relay_auth_password`, which you can generate at https://app.sendgrid.com/settings/api_keys. The API key password looks something like `SG.955oW1mLSfwds7i9Yd6IA5Q.q8GTaB8q9kGDzasegdG6u95fQ-6zkdwrPP8bOeuI`.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
Note that the `exim_relay_relay_auth_username` is literally the string `apikey`, it's always the same for Sendgrid.
```yaml
exim_relay_sender_address:"arbitrary@email.com"
exim_relay_relay_use:true
exim_relay_relay_host_name:"smtp.sendgrid.net"
exim_relay_relay_host_port:587
exim_relay_relay_auth:true
exim_relay_relay_auth_username:"apikey"
exim_relay_relay_auth_password:"<your api key password>"
<!-- 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: `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.
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.