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>
We were overriding the `matrix_bot_matrix_registration_bot_matrix_homeserver_url` variable via `group_vars/matrix_servers`
to point it to the container-local homeserver URL, but this variable was not being used at all.
The actual variable name (which was being used) is `matrix_bot_matrix_registration_bot_api_base_url`.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3898
- Add "To use the bot" if it does not exist: adopt the format of the docs for bridges
- Add "Prerequisites" section if an API key or user account is required
- Use the common instruction for getting an access token
- Replace "Get" with "Obtain" about getting keys or access tokens
- Replace placeholders for access tokens on docs/configuring-playbook-bot-go.neb.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit replaces instructions to create passwords, passphrases, or secrets with common ones.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Provoked by https://github.com/etkecc/mrs/pull/4
I've discovered that Cinny supports various configuration options and it'd be better
if we add support for them.
The common pattern is "Send `.*?` to the bot (in the room) to see the available commands." If the descripions are about a bot being invited to a certain existing room or room which is not DM, then "in the room" is inserted among them.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
REUSE is an initiative by FSFE, which intends to make licensing easier with best practices to display legal information through comment headers on source files that can be easily human and machine readable.
Because these files are new and translation shall involve a lot of people as copyright holders, now is the best time to adopt REUSE. As a first implementation, this commit intentionally limits the scope to i18n directory.
Cherry-picked from c737ed0612e5b8bd5837877df63932d77bdcfcf7 and a2445af6d0100a43d6011b31402b9ae8f0c38f0c
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3841
Most of the preparation for this was done by Suguru Hirahara (https://github.com/luixxiul).
I've merely reorganized/polished the scripts and instructions in the `i18n/` directory.
While translations can happen even now, more work is necessary to
- make the translation flow better (integrating Weblate), etc.
- restore the Github Actions workflows that Suguru Hirahara had already developed to
adapt them to our new workflow
Usage of matrix_alertmanager_receiver_config_matrix_room_mapping is decribed below in the "Adjusting the playbook configuration" much more nicely.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: fix sections title
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: merge configuration sections
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: small edits
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: remove a note abour Pantalaimon's unavailability
Pantalaimon can be installed and it has become available for matrix-bot-draupnir and matrix-bot-mjolnir already.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: edit instruction of setting an alias to the management room
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bot-draupnir.md: remove 'c.' from the section title
The section is not related to choosing E2EE support.
Also: replace the instruction to go to the section with the anchor link.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bot-draupnir.md and docs/configuring-playbook-bot-mjolnir.md: create a section for common configs
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: create "Extending the configuration" sections
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bot-draupnir.md and docs/configuring-playbook-bot-mjolnir.md: create the "End-to-End Encryption support" section
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bot-mjolnir: adjust the section hierarchy
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: replace numbering
This is a follow-up to e5ab17cafd.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: create "Prerequisites" section
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: emphasize necessity of disabling rate limit
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: instruction for discharging rate limit on Synapse
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: edit the placeholder for matrix_bot_draupnir_pantalaimon_password and matrix_bot_mjolnir_pantalaimon_password
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update draupnir and mjolnir docs: add an anchor link to "Configuration with E2EE support"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bot-draupnir.md: move the "Abuse Reports" section above
Also: use "pollReports: true" as an example for extending the configuration.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bot-draupnir.md and docs/configuring-playbook-bot-mjolnir.md: small edits
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: use a common expression
cf. docs/configuring-playbook-alertmanager-receiver.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: integrate the description for installation by Draupnir into our description
Check the original one: 120b37f3ea29101be3baf0856d5d23491db9309e
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-appservice-draupnir-for-all.md: fix a typo
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>
- Replace links to the documentation with ones to projects' README files, if these have been linked to the project directly
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The original ID (`@example:example.com`) has not matched with the user IDs which those pages explained on "Registering the bot account" section.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
"To use the bridge, you need to start a chat with …" is well used among the documentation.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
As using `@alice` and `@bob` on this context is confusing, this commit replaces them with `@email2matrix1` and `@email2matrix2`, respectively.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This commit intends to clarify what "short user ID" means by comparing it with ":matrix.example.com"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The original ID (`@whatever_you_chose:example.com`) has not matched with the user ID which this page explained above on "Registering the bot user" section.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Use common expressions
- Remove a word puzzle for better l10n experience
- Remove a redundant whitespace character
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* set localpart of hookshot bot in main.yml
* set sender_localpart in registration.yml.j2 template to variable
* prettier location for bot localpart in main.yml
* Update main.yml
* Update registration.yml.j2
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
We used to pass the shared secret for double-puppeting via a
`login_shared_secret` parameter, which doesn't seem to exist anymore.
The proper way to do it is via `login_shared_secret_map`.
The comments for `login_shared_secret_map` seem to indicate that it's
only usable with the shared-secret-auth password provider.
However, this bridge is based on mautrix-python (`>=0.20.5,<0.21`) as
per its `requirements.txt`
Support for double-puppeting via arbitrary access tokens landed in
mautrix-python 0.20.1 (6f25b62e80/CHANGELOG.md (L44-L53)),
so it should be possible to use appservice double-puppet.
Related to af04ca1238
A bunch of other parameters seem to have moved around as well.
This patch introduces some new Ansible variables for controlling
additional settings related to encryption, etc.
This way, the "installing" sections would cover from beginners to advanced (professional) readers.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Also: remove the redundant description about that difference from description about the "just" shortcuts.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "just run-tags install-all/setup-all,start" with "just install-all/setup-all"
Thanks to the tip by Slavi that the overhead of ensure-matrix-users-created is negligible.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit installing instructions
- Move the anchor links to docs/just.md
- Add note about running "ensure-matrix-users-created" tags, if ansible-playbook's tags not "setup-all,ensure-matrix-users-created,start", ie. either "setup-all,start", "setup-email2matrix,start", "setup-aux-files,setup-corporal,start", or "setup-matrix-user-verification-service,start"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update descriptions about installation
- Introduce the most conservative and stable raw ansible-playbook command.
- Introduce the just commands on installing.md and maintenance-upgrading-services.md, not on quick-start.md, since it is too early for quick start guide readers who are just starting to climb learning curve to use the shortcuts.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-etherpad.md: remove the note about ensure-matrix-users-created
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>
As the SchildiChat Web docker image was updated with 14a3a01f43 thanks to Aine, the warning is no longer relevant. Note that though the package name says it is a test, it is a test release for SchildiChat Web, and the codebase is Element Web v1.11.86.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace installation command shortcut for the "just" program with the most conservative raw ansible-playbook command
This commit replaces installation command shortcut ("recipe") for the "just" program with the raw ansible-playbook command, so that the shortcut will be added to it later. The command is so conservative that failure of the command will mean something is clearly broken.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add comments about using setup-all instead of install-all
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add description about shortcut command with the "just" program to the ansible-playbook command with "setup-all" and "start" tags
It also explains difference between "just install-all" and "just setup-all" recipes. The explanation is based on docs/playbook-tags.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update raw ansible-playbook command to have it do what "just install-all" or "just setup-all" does
Since "just install-all" or "just setup-all" invokes "ensure-matrix-users-created" as well, it needs adding to the raw ansible-playbook command.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Remove "ensure-matrix-users-created" from the raw ansible-playbook command which does not need it
Also: update the "just" recipes accordingly. "just install-all" and "just setup-all" run "ensure-matrix-users-created" tag as well, therefore they need to be replaced with "run-tags" recipes to skip "ensure-matrix-users-created"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-etherpad.md: add ensure-matrix-users-created to the raw ansible-playbook
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add description about "ensure-matrix-users-created" and create a list with description about shortcut commands with "just"
This commit also fixes list item capitalization and punctuation.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add notes bullet lists
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-matrix-corporal.md and docs/configuring-playbook-email2matrix.md: adopt common instructions
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "run the installation command" with "run the playbook with tags"
Now that shortcut commands for the "just" program are displayed along with the existing "installation command", this commit replaces "run the installation command" with "run the playbook with tags" in order to prevent misunderstanding and confusion.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add notes about changing passwords of users specified on vars.yml
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-synapse-admin.md: add the playbook command and just recipes
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Remove redundant blank lines
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-alertmanager-receiver.md: remove the direction to proceed to Usage
Such a kind of direction is not used on other documentation, so it should be fine to just remove it.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/importing-synapse-media-store.md: code block for ansible-playbook
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-appservice-webhooks.md: apply the common documentation style
Since the bridge has been deprecated, this change is simply intended to improve styling and format of the article in case it will be used as a template of another bridge in a future.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-appservice-discord.md: apply the common documentation style
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-appservice-slack.md: apply the common documentation style
Also: move instruction to create Classic Slack application up as prerequisite
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-appservice-slack.md: emphasize the unavailability without a classic Slack application
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-appservice-kakaotalk.md: fix the header for adjusting the playbook configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Move sections "Set up Double Puppeting" under "Usage" as subsections for mautrix bridges and appservice kakaotalk
The changes in this commit reflect double puppeting configuration flow. Since the docs claim that double puppeting can be set up after enabling bridges by chatting with the bridge's bot, the explanation about double puppeting may well be placed under "Usage" as subsection.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Remove notes about setting up double puppeting manually
Since this method is explained after configuring bridges, those notes are no longer necessary.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs for mautrix and kakaotalk bridges: add prerequisite(s) section for instructing to install Appservice Double Puppet and/or Shared Secret Auth service
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "Enabling Appservice Double Puppet" with "This"
Enabling Appservice Double Puppet is contrasted with "Enabling double puppeting by enabling the Shared Secret Auth service", therefore it can be just called as "this" if Shared Secret Auth service is not mentioned below.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-beeper-linkedin.md: follow other instances
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add 💡 (Light Bulb: U+1F4A1) to the headings
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
---------
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Co-authored-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This is related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3831
It:
- adds some missing variables
- version variable to branch variable conversion
While it improves the situation, it still doesn't result in a working
self-building feature, because:
- cloning a repository containing submodules requires special care,
as described here
(c03ef20e5d/README.md (initial-build-setup))
- we likely better clone a specific repository version from the very beginning, instead of trying to change subsequently (and having to re-initilize submodules)
though that's very different than what we're doing elsewhere and is likely very wasteful
- we can't just build a `Dockerfile`, we need to invoke `make setup` (`./setup.sh`)
- it's likely that the `docker-src` directory is not reusable across
versions or may require special handling to clean up files, etc.
* Triple backticks with syntax highlighting: yml → yaml
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Triple backticks with syntax highlighting: yaml and sh
The strings "yml" were replaced with "yaml" as the latter is used more than the former.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Triple backticks with syntax highlighting: INI
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-jitsi.md: remove redundant white space characters after triple backticks
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/faq.md: replace instruction about restoration procedure with the anchor link to installing.md
Note the link to docs/maintenance-migrating.md is placed on the entry just above.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/faq.md: update description related to installation on matrix.example.com
Summary:
- Copy a paragraph from docs/howto-server-delegation.md
- Simplify instruction to install on matrix.example.com by removing repetitive description
- Remove duplicated description about server delegation
- Replace deprecated (or soon to be deprecated) services on configuration example for inventory/host_vars/matrix.example.com/vars.yml
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/faq.md: fix and simplify the answer to the reason why install your server at matrix.example.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>
* Update docs/README.md: add "installation guides" section
Add the emoji to the link to quick-start.md only and not to full installation guide to emphasize the quick start guide
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: move a link to faq.md down
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: add "Maintenance" section
Add a hint to join the support room under "Maintenance" header.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: create the "configuration options" section and add a note
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: sort list items
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: emphasize the anchor link to faq.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: add other anchor links to the "other documentation pages" section
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: add the emoji ℹ️ before the anchor link to faq.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: explanation about FAQ
Remove the hint to check the installation guides as links to them are listed on top of this page.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/README.md: update text of the anchor link to docs/getting-the-playbook.md
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>
* Edit docs/maintenance-migrating.md: replace the numbering list with sections for each item
Also: add an ansible-playbook command with the stop tag as the main command to stop the Matrix services.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/maintenance-migrating.md: move the note under the header
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/maintenance-migrating.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/maintenance-migrating.md: add a section "checking if services work"
The commit does not include the detail as having another similar section increases doubles effort to maintain them and increases possibility of causing discrepancy.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/maintenance-migrating.md: add a note about joining the support room on Matrix
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/maintenance-migrating.md: replace hosts with inventory/hosts
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/maintenance-migrating.md: instruction to run ansible-playbook commands locally
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/maintenance-migrating.md: edit the check section
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/maintenance-migrating.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/maintenance-migrating.md: reflect the review and edit a note for creating a temporary account on another server
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Minor rewording in maintenance-migrating.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>
This is a follow-up to 5483925ee4.
Since any-of-issue/pr-labels overrides any-of-labels, the values specified by the latter need to be specified by the former.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Without this option, stale counters for each PR keep restarting whenever any update occurs or a comment is added to them. Since the counters for PR are set to 365 days, ignore-pr-updates should help us to get rid of zombie PRs (which are kept open by bumps).
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add docs/just.md as dedicated documentation of "just" commands
This is partially based on fb60ba67f6 (announcement of adoption of "just" program). It also refers descriptions on installing.md.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Create a table for examples
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Fix entries on the table
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Move the anchor link to "agru"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/faq.md: add an entry for the just
It is based on the existing explanation of the just on docs/maintenance-upgrading-services.md.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add links to docs/just.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/just.md: add a common note
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Clarify "What is just" section on FAQ
* Update just.md
* Mention install-service
---------
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 docs/quick-start.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add description about keeping the playbook and services up-to-date
Also: move descriptions about difference between the playbook tags (setup-all and install-all) and about the just "recipe" from installing.md to maintenance-upgrading-services.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace <your-username> with YOUR_USERNAME_HERE
This is a common expression and should avoid misunderstanding that `<` and `>` would need to be included
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace <your-password> with YOUR_PASSWORD_HERE
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Change the link to 'Quick start' on the breadcrumbs from README.md to quick-start.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add a link to quick-start.md on the "Getting started" section
Since I am not quite sure whether the link to prerequisites.md should be replaced in favor of this link, this commit leaves it as it is for now.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add a link to quick-start.md on docs/README.md
Since I am not quite sure whether the link to prerequisites.md should be replaced in favor of this link, this commit leaves it as it is for now.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add note about using "example.com" as an example domain
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Remove backticks from command examples to register a user
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Improve notes for instruction to create a user account
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add details about delegation to installing.md and quick-start.md
Some information is omitted on quick-start.md in favor of installing.md to keep the quick start guide simple.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/quick-start.md: add the breadcrumb header
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Edit docs/quick-start.md: run the setup command with install-all by default
Refer docs/maintenance-upgrading-services.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Revert "Update docs/quick-start.md: add the breadcrumb header"
This reverts commit 9a6e1cf14c7638953fc8fbb8b487ea0afd0a41ad.
As the quick start guide is standalone.
* Update docs/quick-start.md: add headers inside the install section
These headers should make it perfectly clear that there are two steps to be done to install with the playbook
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update quick-start.md
* Update docs/registering-users.md: notes for manual user registeration
Copy the same notes from quick-start.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Reword some things in quick start
* Add alternative to `just roles`
* Update docs/configuring-dns.md: sync with docs/quick-start.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/quick-start.md: add a link to docs/registering-users.md for an instruction to add user accounts
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/registering-users.md and docs/updating-users-passwords.md: remove "your" from username and password placeholders
These documentations, unlike docs/installing.md and docs/quick-start.md, describe how to handle users (registering them or changing their passwords), some of whom are yours, while others are not.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md: add "your" to make it clear that it is "your" account that is going to be created
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md and docs/quick-start.md: mention "make roles"
This commit adds mentions to "make roles" and a note about the preference of ansible-playbook commands over the just "recipes".
quick-start.md intends to be referred by those who have never used the playbook to set up a server, so it is safer to regard that it is not clear to them what exactly the just "recipes" are made of, ie. it takes some time and experience until someone understands simplicity of them. For beginners, I believe that we should prefer the basics over simplicity, from the educational point of view.
If someone feels tired of using the same command repetitively, then the person will have been already well accustomed to the way how the playbook works and how the server is supposed to be maintained, and the person is "qualified" to use the just "recipes", and should be able to use them with confidence, distinguishing the playbook tags from the "recipes", for example, from "just install-all" and "ansible-playbook -i inventory/hosts setup.yml --tags=install-all". Such level of familiarity and experience should not be expected on the quick start guide.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update instructions to update Ansible roles
Also: move the detailed explanation about "just roles" from installing.md to maintenance-upgrading-services.md
TBD: create a dedicated documentation for the "just" program and the concept of its "recipe" (shortcut of commands)
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add a note about cases to create multiple accounts/users
Since one of the quick start guide's goals is to set up an own user account, this commit adds the note about creating multiple accounts/users to installing.md and registering-users.md only. It should be fine as registering-users.md is linked from quick-start.md
Also:
- On installing.md and quick-start.md, change instruction from what encourages to select "admin=yes" or "admin=no" to what encourages to use "admin=yes", since your user account will be the sole user on the server, as long as you set up the server by following the documentation
- Remove the link to registering-users.md from quick-start.md as the documentation is already linked above, under the header of the section
- Sync docs/installing.md with other documentation
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Remove a line about setting "admin=yes" to reduce the amount of information
Because quick-start.md is getting longer with much information, it removes the note in favor of the linked registering-users.md documentation. The note is available on installing.md as well, and details about adding user accounts for other people can (and should) be checked on those documentations.
Also, this commit edits lines above these notes to make it clear that your user account will be an administrator of the server.
With this commit, the amount of the information about adding user accounts will be: registering-users.md > installing.md > quick-start.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Fix a broken anchor link on docs/installing.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace repetitive information about upgrading with an anchor link to docs/maintenance-upgrading-services.md
Because details to update/upgrade the Matrix services is not necessary for quick start and the amount of information should be reduced from the viewpoint of maintainability, this commit removes details to update/upgrade from quick-start.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/quick-start.md: add a note about keeping it tidy and simple
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/maintenance-checking-services.md and docs/quick-start.md: add instruction to use federation tester against the base domain
Per Slavi's suggestion.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md and docs/quick-start.md: replace commands to finalize the installation
Per Slavi's suggestion.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Clarify install-matrix-static-files to avoid confusion with install-all; Minor consistency improvements
---------
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>
This change makes it possible for terminals to render warning emoji in actual emoji (⚠️), not in text style (⚠).
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
With this commit, actions/stale on GitHub will add a label 'stale' on issues (on spantaleev/matrix-docker-ansible-deploy) after 60 days of inactivity and close the stale issues after 7 days of inactivity. Only issues with labels 'question' and/or 'needs-info' will be processed, and ones with a label 'confirmed' will not be processed automatically.
Please refer https://github.com/marketplace/actions/close-stale-issues
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ma1sd.md: edit top paragraphs
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ma1sd.md: use common expressions for instruction to add configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ma1sd.md: move instructions up
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ma1sd.md: move the instruction for additional features up
Move instructions for features which use the "matrix_ma1sd_configuration_extension_yaml" variable under "Additional features".
Also: adjust headers' level
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ma1sd.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update configuring-playbook-ma1sd.md: adjust to follow other examples such as on configuring-playbook-bridge-appservice-webhooks.md
This commit:
- Move the note about installing to the top
- Add warning emoji (⚠️: U+26A0 FE0F)
- Use a common expression to discourage installing
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-ma1sd.md: move instruction to configure DNS settings up
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Fix typo and add an extra newline
---------
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>
Since it is required to create and input a strong password (random strings) on vars.yml, this commit adds a password generator as a required software to configure and run the playbook. Password Tech, reportedly formerly known as "PWGen for Windows", is linked from https://github.com/jbernard/pwgen
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md: add "Create your user account" section before "Finalize the installation"
docs/registering-users.md has correctly instructed that service delegation should be conducted after creating user accounts to finalize the installation process.
Since it does not really make sense to claim that installation has finished if there is not a user, this commit adds instruction to create a user account before configuring server delegation.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update installing.md: remove a whitespace character
---------
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-dns.md: add note about DNS settings for default services
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md and docs/configuring-playbook-ma1sd.md: move the DNS setting (SRV record) for ma1sd to the latter
Edit instruction to enable a SRV record for ma1sd.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: remove repetitive explanations about necessity of subdomain settings
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: move explanation about subdomain settings up
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: fix tables layout
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: edit the section for TXT and MX records
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: move the row for ma1sd under the rows for CNAME records
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: replace "may be necessary" with "is necessary" as Element Web is installed by default
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: add a note about setting a SRV record for ma1sd
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: use the same string for IP address placeholder
Also: adjust the table's layout
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: simplify the header for postmoogle DNS records configuration
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: switch the order of TXT and MX moogle for Postmoogle
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: simplify instructions for ma1sd and Postmoogle
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-dns.md: fix the anchor link to rageshake documentation
The issue was introduced with ea6e879487
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>
Essentially it means "configuring your DNS settings or records on the DNS server you use".
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The current ToC was added by 065b70203d, but the links were initially added by ef903fe544 as a navigation to sections under them. This commit replaces the ToC with such navigation.
Also, one of the sections was removed by f4f3d57520, and since matrix-nginx-proxy was removed, it seems to me that letting Synapse handle Federation by itself would be simpler than the other method which requires setting another webserver. Therefore this commit switches the alternative method from using another webserver to using Synapse.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-base-domain-serving.md: add an anchor link to docs/configuring-dns.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update documentation related to server delegation
Summary:
- Add explanation about server delegation and DNS setting for it to docs/configuring-dns.md; "delegation" is a technical term and it is worth being explained simply
- Edit explanation about delegation to docs/configuring-playbook-base-domain-serving.md
- Use common expressions
- Simplify explanation about delegation on docs/configuring-well-known.md and move explanation about the alternative which avoids involving the base domain from that page to its upper documentation, which is docs/howto-server-delegation.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-dns.md: iterate
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Fix an anchor link to howto-srv-server-delegation.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Minor rewording
* Minor rewording
* Minor rewording
---------
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>
This commit clarifies the hierarchy among pages for installation by moving articles for importing data and server delegation under the "installation" section, as there are multiple documentation pages which discuss a similar topic and you can easily get lost in those pages.
Also: remove the anchor link to configuring-playbook-base-domain-serving.md from configuring-playbook.md, since that procedure is not required on configuring options but on finalizing the installation, which is discussed on installing.md after that page.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: remove redundant information
For example, anchor links to the headers are distractive as these headers are displayed by scrolling a bit.
Also: edit section headers
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: add "Support service discovery" as a type of well-known service discovery
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: recategorize the sections about installing well-known files on the base domain's server
The commit merges the content of the option 2 with the section above, as both explain how to serve the base domain via the playbook and claim it is the easy way of installing well-known files, and therefore the content is repetitive.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: create a section for types of well-known service discovery mechanism
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: add a link to the Matrix Specification, to which MSC 1929 was implemented
MSC 1929 has no longer been for an early adopter.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: iterate
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-base-domain-serving.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-well-known.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/installing.md: iterate
Summary:
- Try to reflect review comments
- Declare that the shorter user identifier is recommended
- Add a note about installing the server matrix.example.com directly, with the link to the FAQ entry
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/installing.md: replace the anchor link to docs/configuring-well-known.md with one to docs/howto-server-delegation.md
Service Discovery via .well-known files is one of the two ways for server delegation, and it is possible to set up server delegation via a DNS SRV record instead (though it is more advanced and complicated), so it should be more proper to use the words "delegation/redirection" than "service discovery".
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-well-known.md: fix a typo
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>
This merely hooks the playbook to the Traefik role's compression
middleware configuration (`traefik_config_http_middlewares_compression_*`)
The Traefik role enables the `compression` middleware by default.
Actual usage will land in a future commit.
gzipping certain responses is known to cause problems with QR code logins.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3749
Gzipping at the synapse-reverse-proxy-companion level and not at the
level of the outer-most reverse-proxy (Traefik) also sounds non-ideal.
This change only affects setups powered by Synapse workers.
Non-worker setups (and setups powered by other homeservers) were not
having their requests go through synapse-reverse-proxy-companion anyway,
so this change does not affect them.
Future patches may enable response compression support at the Traefik level for
all setups.
The concept of the just recipe is explained at the bottom of the page, therefore it should be safe to avoid using it here and prefer the ansible-playbook command like above.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Until recently there have been a lot of questions about installing, which could have been avoided if required software such as compatible version of Ansible was installed. This note should encourage those who experience basic error to troubleshoot before giving up.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The playbook tags are not limited to installation, and the explanation's detail makes the section worth being split to a dedicated individual page.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Maintenance work by running the playbook will be required after finalizing the installation
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The instruction describes the easiest way of configuring Service Discovery (which is required for federation) should help to understand what basically to be done to finalize the installation.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Since a casual user might want to try another homeserver than Synapse without thinking about its consequence, it is important to clarify that it is not possible to switch homeservers once specified.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "Element" with "Element Web"
- If Element indicates the web application, then it is changed to Element Web.
- If it indicates clients branded with Element such as Element desktop, web, mobile clients, then it is changed to Element clients.
- If it is combined with location sharing functionality, it is not changed.
with other some changes, including:
- Change "app.element.io" anchor link to "https://github.com/element-hq/element-web" on README.md, following other documentation files
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace "SchildiChat" with "SchildiChat Web"
- If SchildiChat indicates the web application, then it is changed to SchildiChat Web.
- If it indicates clients branded with SchildiChat such as SchildiChat desktop, web, mobile clients, then it is changed to SchildiChat clients.
- If it is combined with location sharing functionality, it is not changed.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename configuring-playbook-client-schildichat.md to configuring-playbook-client-schildichat-web.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename configuring-playbook-client-element.md to configuring-playbook-client-element-web.md
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>
✓ and x indicators provide less visibility, as they're very similarly
looking.
Emojis (especially when colored) make it much easier to see which
component is a default one and which isn't.
Section headings are also prefixed with an emoji now to make
decrease the "wall of text" feeling.
* Add hard-coded breadcrumbs to documentation files about installation procedure for easier navigation
Since it is easy to get lost among these files, the breadcrumbs should be helpful to get the whole picture of the procedure. Hopefully they will be replaced with something else generated automatically.
Please note that the usage of <sup> HTML tags on this context is not proper as the tag is intended to be used only for typographical reasons. Here <small> tags should rather be used instead as long as we do not use CSS, but since GitHub strips these tags against its spec (https://github.github.com/gfm/#disallowed-raw-html-extension-) (also note: the <small> HTML tags are not stripped on Codeberg for example), this commit intentionally uses <sup> to have those breadcrumbs rendered in small points.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook.md title
The file is referred from other files as "Configuring the playbook"
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add "Quick start" link with the thunder icon
For now docs/README.md is linked
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>
People should be made aware of the status of this component as soon as
possible.
This is consitent with the positioning of Note messages we have for other deprecated
components (e.g. bot-chatgpt, bot-go-neb, etc).
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3735
The note is for those who are not familiar with the playbook's tag and its just recipe.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Also: update README.md and docs/container-images.md
Move Sygnal and ntfy from "Server Components" to "Misc", following the existing categorization on docs/configuring-playbook.md where they are categorized as "Other specialzed services". This categorization makes more sense as they are not really services which make the components on the server work (per README.md)
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Setting "optional" is redundant for those entries, as all of them are under the heading "Other configuration options" and it is obvious that those settings are optional.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Use a common expression for adjusting configuration. As the component has been deprecated, this is purely for future use as a template.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The URL stopped working since some time. Linking to the internal file will keep working as long as the URL is properly managed.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Disable blank (without using a template) issue
- Add a contact link to the support room on Matrix
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This is essentially an imitation of 59a01dabfc for container images. It copies the entries order and descriptions on the table of README.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The user ID of the new bridge (mautrix-meta) is different from that of the old bridge (mautrix-facebook). It is slightly confusing, and the note should help migration.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Since nginx has been replaced with traefik, the documentation is getting irrelevant anyway.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
matrix-appservice-kakaotalk itself was added to the playbook with e46ba5deba. It also does not provide its container image.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update docs/configuring-playbook-bridge-hookshot.md: matrix-appservice-webhooks has been deprecated
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add notes that matrix-appservice-slack is not available for new installation
The bridge uses a classic Slack application, but its creation has been discontinued since June 4, 2024.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Remove reference to matrix-hookshot and matrix-appservice-webhooks
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>
* Rename variables matrix_bot_postmoogle_* with matrix_postmoogle_*
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename file names and references to those files
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Move variables block for /matrix-bridge-postmoogle
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Rename matrix_playbook_bot_postmoogle_ to matrix_playbook_bridge_postmoogle_
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Add matrix_playbook_migration_matrix_postmoogle_migration_validation_enabled
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Replace an install tag example with "-bot" prefix
The previous example seems to have been selected to show how components whose name contains "-bot-" needed to be specified.
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>
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3701
We can restore support for it by making a non-/ path prefix trigger a
self-build with a modified build config, so that a Cinny version with
path-prefix support would be produced. Traefik label changes may also be
required.
For now, we're not doing all that work, but simply dropping support for path
prefixes for Cinny.
The original synapse-admin (Awesome-Technologies/synapse-admin) was replaced with etke.cc/synapse-admin with 73d338d9d1 on Sep 12, 2024.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update configuring-playbook.md: move a link for docs/configuring-playbook-bot-postmoogle.md to Bots section
The document (on 9c2a8addee93910cb9079f856bc3fb3932592c91; initial commit to add Postmoogle) says:
> Postmoogle is a bot/bridge you can use to forward emails to Matrix rooms
Therefore it is not really incorrect to categorize Postmoogle as bridge document-wise, but since the list on README.md categorizes it as a bot, and based on the file name of the documentation, this commit moves the link for Postmoogle to the Bots section.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Revert "Update configuring-playbook.md: move a link for docs/configuring-playbook-bot-postmoogle.md to Bots section"
This reverts commit 1e2e903cb955fcf5033788c508816293b837e9f5.
* Change the file name of Postmoogle documentation to make it clear that Postmoogle is a bridge
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
* Update documentation for Postmoogle related to a bridge/bot status
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 switch to element-hq/synapse was conducted with aa0a85b094.
Since the fork no longer belongs to Matrix Foundation, it is not quite "official" anymore, while it is enabled by default and not optional.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Note that links to the issues and PRs on the original repository (matrix-org/synapse) should not be replaced with ones on the forked one (element-hq/synapse) as those are not available on the latter, where the issues and PRs with the same number as matrix-org/synapse are "reserved" to avoid conflicts between those repositories. For reasoning of such complexity (including the reason why trasferring the original repository to element-hq/synapse was avoided), see: https://github.com/element-hq/synapse/issues/6#issuecomment-1861116896
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
It is a legacy of docs/configuring-playbook-s3.md on ac7cb3619d, and the upper levels of those two list items are redundant.
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
In order to avoid confusions between the name of the program itself (BorgBackup and Borg in short) and the backups managed by BorgBackup, the official full name should be preferred where possible, minding capitalization.
- Borg or borg → BorgBackup
- Borg backup(s) → BorgBackup (if it means the program) / backups with BorgBackup (if it means the backups managed by the program)
Based on https://www.borgbackup.org/
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Based on https://github.com/turt2live/matrix-dimension
> An open source integration manager for matrix clients, like Element.
"Dimension" is one of the integration managers, and it is not something like Dimension Integration Manager, which could be abbreviated as DIM.
Also:
- Replace "integrations manager" with "integration manager"
- Fix typos
- Remove a line break
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This adopts the structure of docs/configuring-playbook-matrix-authentication-service.md which was recently created.
- …
- Adjusting the playbook configuration
- …
- Adjusting the (service name here) URL
- …
- Adjusting DNS records
- Installing
- …
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
This adopts the structure of docs/configuring-playbook-matrix-authentication-service.md which was recently created.
- …
- Adjusting the playbook configuration
- …
- Adjusting the (service name here) URL
- …
- Adjusting DNS records
- Installing
- …
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
exim_relay_sender_address consists of exim_relay_hostname, which by default is equal to matrix_server_fqn_matrix, whose default value is matrix.example.com
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
- Use a common expression for a comment
- Use a common expression for usage instruction
- Fix typos
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Overall the playbook uses the expression "Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file:" with the heading "Adjusting the playbook configuration" for sections to explain what to be added as variables
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
Make the paragraph consistent with files such as:
- docs/configuring-playbook-bot-baibot.md
- docs/configuring-playbook-bot-buscarron.md
- docs/configuring-playbook-bot-honoroit.md
Signed-off-by: Suguru Hirahara <acioustick@noreply.codeberg.org>
The new prompt makes use of the new `baibot_conversation_start_time_utc`
prompt variable, which is not a moving target (like `baibot_now_utc`)
and as such allows prompt caching to work.
Ref: https://platform.openai.com/docs/guides/prompt-caching
Since 2024-10-02, `gpt-4o` is actually the same as `gpt-4o-2024-08-06`.
We previously used `gpt-4o-2024-08-06`, because it was pointing to a
much better (longer context) model. Since they're both the same now,
we'd better stick to the unpinned model and make it easier for future
users to get upgrades.
`gpt-4o` will point to `gpt-4o-2024-08-06` after 2nd of October 2024
anyway. At that time, we can revert to pointing to `gpt-4o`.
The reason `gpt-4o-2024-08-06` was chosen now instead of `gpt-4o`:
- the `max_response_tokens` configuration was set to 16k, which matches
`gpt-4o-2024-08-06`, but is too large for `gpt-4o` (max 4k)
- baibot's own configs for dynamically created agents, as well as static
config examples use `gpt-4o-2024-08-06` and the larger
`max_response_tokens` value
The playbook did not use to define a prompt for statically-defined
agents.
Since prompt variables support landed in v1.1.0
(see 2a5a2d6a4d)
it makes sense to make use of it for a better out-of-the-box experience
(see https://github.com/etkecc/baibot/issues/10).
Seems like `default` is not a supported value and will not
make the bridge autoconfigure itself with the correct prefix anymore.
A value of `default` would be taken literally.
We'be already been going against upstream defaults and have been
enabling backfilling for a few other bridges (Messenger, Instagram, Telegram, Twitter).
Now I'm enabling backfilling by default for the remaining ones, for
consistency.
While working on upgrading the Meta bridges to bridgev2, I've noticed
that {% raw %} and {% endraw %} on lines like that (immediately
preceding `username_template` may cause YAML indentation issues.
* Added an example of fronting the playbook's integrated Traefik reverse-proxy with the existing Caddy container (not the `apt-get` or `yum` installed Caddy). Helpful for folks who have an existing server with a Caddy container already serving multiple applications.
* Update examples/reverse-proxies/caddy2-in-container/README.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update examples/reverse-proxies/caddy2-in-container/README.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update examples/reverse-proxies/caddy2-in-container/README.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Code formatted, linted with yamllint
* README.md updated
* docs/configuring-playbook-own-webserver-caddy.md removed
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update configuring-playbook-bot-maubot.md
added info to avoid using Element Access Token because it will prevent the bot from functioning properly in the Encrypted room.
Also added maubot simple service management on how to stop and start the maubot service
* Update configuring-playbook-bot-maubot.md
remove generic messages and change from backtick to bold
* Rewording in configuring-playbook-bot-maubot.md
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Since upgrading mautrix-slack (and pinning to v0.1.0) in e4b54c37fe,
we expect double-puppeting to require the new appservice double-puppeting method.
This commit switches the mautrix-slack bridge to it.
Since upgrading mautrix-signal (v0.6.3 -> v0.7.0) in 76fec0b863,
we expect double-puppeting to require the new appservice double-puppeting method.
This commit switches the mautrix-signal bridge to it.
* add synapse-auto-compressor workaround, fixes#3397
* Clarify what the PG-prefixed variables are for
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Add DNS-01 challenge to configuring-playbook-ssl-certificates.md
* Minor rewording to the DNS-01 challenge type documentation
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
No need to duplicate the same logic as in `group_vars/matrix_servers`.
Having it disabled by default in the role itself and overriding it at the playbook level (based on the selected homeserver implementation) makes more sense.
* update http2 config due to deprecation
the previous way to let `http2` follow a `listen` was depracated, it
moved to `http2 on;`
* enable quic and http3
I hope the comments are somewhat understandable. if someone can describe
the `reuseport` part more concise, please do.
Cinny includes nginx configuration which does URL rewrites now, as seen
here: https://raw.githubusercontent.com/cinnyapp/cinny/dev/docker-nginx.conf
That said, we have our own nginx configuration for Cinny, because we'd
like to run ngin as non-root and on a non-privileged port (80 -> 8080).
For this reason, we override `/etc/nginx/nginx.conf` and need to
duplicate what we see in `/etc/nginx/conf.d/default.conf` with our own
`server` block (which listens on port 8080).
* rewrite `just update` command to provide a one-line command to update everything
* update prefix
* uncomment update-self
* Revert requirements.yml updates not belonging to this PR
* Justfile and documentation updates to make things clearer
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This is provoked by de91fe933d,
where I've added a few new labels and made it possible for people to
disable them.
In this patch, I'm making it possible to disable any of the old Traefik
labels in a similar way.
My alerts seem to contain `annotations.alertname` in the payload, so the
default configuration (coming from the matrix-alertmanager-receiver README)
seems to be outdated or something.
* Add public url for gitlab hookshot to autocreate webhook on gitlab instance
* Add `noqa var-naming` comment to variable
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* honoroit v0.9.22
* Add more spaces before comments to make yamllint happy
* Add more spaces before comment to make yamllint happy
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
`matrix-media-repo` is the only role that seems incompatible with the
changes introduced by Traefik v3, due to its use of `PathPrefix` with
regular expressions in a few places.
Regular expressions should now be used with `PathRegexp`, not
`PathPrefix`. Furthermore, they should follow the Golang regexp syntax,
as described in the migration guide:
https://doc.traefik.io/traefik/migration/v2-to-v3-details/#dynamic-configuration-changes
This reverts commit 752de4406e.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3393
When running the playbook against an existing server, it invokes `register_new_matrix_user`
as part of the `matrix-user-creator` role, which runs before the
`systemd_service_manager`. At that time, `matrix-user-creator` detects
that Synapse is up (from before), but it's the old version. Services have not yet been
restarted, so it's actually the older Synapse version that is up, not
the new one. The old version does not support the `--exists-ok` flag yet.
Basically, this `--exists-ok` patch landed too early and has affected existing playbook
users that have an older version of Synapse in operation.
It will be safer to bring back this patch some time in the future.
However, users upgrading from Synapse <= v1.109.0 even long into the
future will bump into the same issue. As such, it would be better to
either add special handling or to delay bringing back this patch enough
so as to ensure everyone using the playbook is on Synapse >= 1.110.0.
`auto_join_mxid_localpart` defines the local part of the user id which is used to create auto-join rooms. The variable needs to be set to invite new users to any auto-join rooms which are set to invite-only.
By appending `/webhook` to the public URL (becoming `/hookshot/webhooks/webhook`)
and by only stripping the `/hookshot/webhooks` prefix,
we're effectively following what newer Hookshot versions advise
(see https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1681).
This change appears to be backward-compatible (old webhook URLs like `/hookshot/webhooks/:hookId` still work),
until Hookshot behavior changes.
Regression since 7891268873,
where I removed the `matrix_hookshot_urlprefix` prefix group
`group_vars/matrix_servers`, thinking the value in `roles/custom/matrix-bridge-hookshot/defaults/main.yml`
was the same.
The value in `defaults/main.yml` incorrectly included `matrix_hookshot_public_endpoint`
in `matrix_hookshot_urlprefix`, which was leading to double-`/hookshot`-prefixing.
We were previously saved by the `matrix_hookshot_urlprefix` override in `group_vars/matrix_servers`.
This fix brings the correct URL prefix value (the one without `matrix_hookshot_public_endpoint`)
to `defaults/main.yml`.
Commit 4224741130 missed a endfor
statement in the goofys systemd service unit template. This adds it,
avoiding a Jinja2 syntax error when using goofys.
Related to 0241c71a4c
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3270#issuecomment-2143782962
With this change, it should be possible for people to adjust the Docker
dependency from `docker.service` to something else (e.g. `pkg-ContainerManager-dockerd.service`),
or to completely eliminate it by setting `devture_systemd_docker_base_docker_service_name` to an empty string.
This makes it easier for people to use the playbook against a Synology DSM server.
This is based on the PR (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3241)
by Tobias Diez (https://github.com/tobiasdiez).
I've refactored some parts, made it more configurable, polished it up,
and it's integrated into the playbook now.
Both the WeChat bridge and WeChat agent appear to be working.
The WeChat bridge joins rooms and responds as expected.
That said, end-to-end testing (actually bridging to a WeChat account) has not been done yet.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/701
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3092
This is sponsored https://etke.cc/ work related to https://gitlab.com/etke.cc/ansible/-/issues/2
Squashed commit of the following:
commit fdd37f02472a0b83d61b4fac80650442f90e7629
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 21:05:53 2024 +0300
Add documentation for WeChat bridge
commit 8426fc8b95bb160ea7f9659bd45bc59cf1326614
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:59:42 2024 +0300
Rename directory for matrix_wechat_agent_container_src_files_path
commit da200df82bbc9153d307095dd90e4769c400ea1e
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:58:26 2024 +0300
Make WeChat listen_secret configurable and auto-configured via matrix_homeserver_generic_secret_key
commit 4022cb1355828ac16af7d9228cb1066962bb35f5
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:54:56 2024 +0300
Refactor install.yml for WeChat a bit (using blocks, etc.)
commit d07a39b4c4f6b93d04204e13e384086d5a242d52
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:52:35 2024 +0300
Rename WeChat Agent configuration file
This makes it more clear that it belongs to the agent.
Otherwise, `config.yaml` and `configure.yaml` make you wonder.
commit ccca72f8d1e602f7c42f4bd552193afa153c9b9d
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:49:06 2024 +0300
Move WeChat agent configuration to a template
commit a4047d94d8877b4095712dfc76ac3082a1edca28
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:47:17 2024 +0300
Mount WeChat config as readonly and instruct bridge to not update it
commit bc0e89f345bf14bbdbfd574bb60d93918c2ac053
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:46:33 2024 +0300
Sync WeChat config with upstream
Brings up-to-date with:
https://github.com/duo/matrix-wechat/commits/0.2.4/example-config.yaml
commit a46f5b9cbc8bf16042685a18c77d25a606bc8232
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:48:17 2024 +0300
Rename some files
commit 3877679040cffc4ca6cccfa21a7335f8f796f06e
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:47:10 2024 +0300
Update WeChat logging config
This brings it up-to-date with what mautrix-go uses.
Otherwise, on startup we see:
> Migrating legacy log config
.. and it gets migrated to what we've done here.
commit e3e95ab234651867c7a975a08455549b31db4172
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:43:37 2024 +0300
Make sure matrix-wechat-agent runs as 1000:1000
It needs to write stuff to `/home/user/.vnc`.
`/home/user` is owned by `user:group` (`1000:1000`), so it cannot run
any other way.
Previously, if the `matrix` user was uid=1000 by chance, it would work,
but that's pure luck.
commit 4d5748ae9b84c81d6b48b0a41b790339d9ac4724
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:57:09 2024 +0300
Pin wechat and wechat-agent versions
commit 40d40009f19ebceed4126146cbb510a2c95af671
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:53:58 2024 +0300
docker_image -> container_image for WeChat bridge
commit cc33aff592541913070d13288d17b04ed6243176
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:00:25 2024 +0300
docker_src -> container_src in WeChat bridge
commit 42e6ae9a6483c8ca6d53b8052058d41d90d93797
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 17:54:24 2024 +0300
matrix_go_wechat_ -> matrix_wechat_
The bridge is written in Go, but does not include Go anywhere in its
name. As such, it's mostly useless to use `matrix_go_wechat` as the
prefix.
commit d6662a69d1916d215d5184320c36d2ef73afd3e9
Author: Tobias Diez <code@tobiasdiez.de>
Date: Mon Mar 25 10:55:16 2024 +0800
Add wechat bridge
Related to 2c40dfd9b8 (commitcomment-142588565)
It seems like there's no published container image with a 2.52.1 tag
and there's also no Prometheus 2.52.1 release yet.
The conditional check 'matrix_hookshot_experimental_encryption_enabled and matrix_hookshot_cache_redisUri == ''' failed. The error was: An unhandled exception occurred while templating '{{ ('redis://' + matrix_hookshot_cache_redis_host + ':' + matrix_hookshot_cache_redis_port) if matrix_hookshot_cache_redis_host else '' }}'. Error was a <class 'ansible.errors.AnsibleError'>, original message: Unexpected templating type error occurred on ({{ ('redis://' + matrix_hookshot_cache_redis_host + ':' + matrix_hookshot_cache_redis_port) if matrix_hookshot_cache_redis_host else '' }}): can only concatenate str (not \"int\") to str. can only concatenate str (not \"int\") to str
Only `amd64` and `arm64` actually work.
The KeyDB role includes a validation task and will complain about
unsupported architectures (like `arm32`).
`arm32` users can stick to Redis for now (`keydb_enabled: false` + `redis_enabled: true`) until:
- the KeyDB role starts supporting self-building.. although building such large
projects on weak CPUs is probably impractical
- a prebuilt arm32 image is made available by other means
This reverts commit 9c01d875f3.
This is very confusing and messy.. but it's documented.
`ansible_become_*` variables actually take priority and override all `become_*`
variables set at the task level.
As such, using `ansible_become=true ansible_become_user=root` in
`inventory/hosts` causes issues because tasks that specify
`become: OTHER_USER` will be forced to run as `root` due to
`ansible_become_user`.
Appservice Draupnir for All required Develop before the release of 1.87.0 to work at all in the playbook. Now that we have a release to pin to we will return to being pinned to a release. Especially as Draupnir 2.0.0 push is happening now in main. This will mean that Draupnir develop is expected to be much more unstable than usual for a bit so its important that we pin to a stable release. These releases are validated due to having been dogfooded ever since D4A was merged into the playbook.
commit cf8637efaca0a0be3609fd6add0dff893a0a9194
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:14:57 2024 +0200
Make devture_systemd_docker_base_ipv6_enabled automatically reconfigure geerlingguy/ansible-role-docker
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit dc7af3bc7d25f321bf409477d823e43ea8a05803
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:10:31 2024 +0200
Replace matrix_ipv6_enabled with devture_systemd_docker_base_ipv6_enabled
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit 07e900d6a2926233a4fce34d9d8be292ff115260
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:01:51 2024 +0200
Improve matrix_ipv6_enabled comments
commit 3f03ca7f6983cb06b64607efef7a96b30c7def5b
Author: Tilo Spannagel <development@tilosp.de>
Date: Sat Mar 9 19:27:50 2024 +0000
Add setting to enable ipv6
In the process of writing the Draupnir for all role documentation it was forgotten that Draupnir needs to have the ability to write to the main management room policy list that controls who can access the bot. This flaw was overlooked during development as naturally without thinking the bot had these powers.
Upstream Docs had this exact bug also and the author of this commit will have to go and fix upstream docs also to resolve this bug.
* Draupnir for all Role
* Draupnir for all Documentation
* Pin D4A to Develop until D4A patches are in a release.
* Update D4A Docs to mention pros and cons of D4A mode compared to normal
* Change Documentation to mention a fixed simpler provisioning flow.
Use of /plain allows us to bypass the bugs encountered during the development of this role with clients attempting to escape our wildcards causing the grief that led to using curl.
This reworded commit does still explain you can automatically inject stuff into the room if you wanted to.
* Emphasise the State of D4A mode
* Link to Draupnir-for-all docs and tweak the docs some
* Link to Draupnir-for-all from Draupnir documentation page
* Announce Draupnir-for-all
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
We still remain on v0.1.0 for now, even though that's quite old nowadays
and the bridge is moving quickly.
Still, one could now pin to a specific commit like this:
```yml
matrix_mautrix_meta_messenger_version: 682c4d75b0fdfe102af4b6d88bb5c76453adc86d
matrix_mautrix_meta_instagram_version: 682c4d75b0fdfe102af4b6d88bb5c76453adc86d
```
* mautrix-meta: enable spaces; add a hint into the display name
* use the meta mode to determine displayname suffix
* Allow for people to easily unset the mautrix-meta displayname suffix
Previously, unsetting `matrix_mautrix_meta_messenger_bridge_displayname_suffix`
or (`matrix_mautrix_meta_instagram_bridge_displayname_suffix`) variable would
make you end up witha trailing space in `displayname`.
It's possible that mautrix-meta trims this, but I haven't checked. It's
better not to risk it anyway.
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
We noticed that the reporting function in Element is broken, at least when using the 'specialized-workers' preset.
This changes the `main_override_locations_regex` of the reverse proxy companion to ensure that requests to `/_matrix/client/v3/rooms/<roomid>/report/<message>` always land on the main process.
We may have had another migration task before, but I cannot find it now.
Some people have reported a leftover systemd timer and service,
so it's evident that not everyone has gone through that previous migration.
The new version is very broken. It has at least 2 issues.
The first one is:
```
Error: maxPromptTokens + max_tokens (3097 + 1024 = 4121) must be less than or equal to maxContextTokens (4097)
at ChatGPTClient.setOptions (file:///usr/src/app/node_modules/@waylaidwanderer/chatgpt-api/src/ChatGPTClient.js:72:19)
at new ChatGPTClient (file:///usr/src/app/node_modules/@waylaidwanderer/chatgpt-api/src/ChatGPTClient.js:23:14)
at main (file:///usr/src/app/dist/index.js:62:21)
at file:///usr/src/app/dist/index.js:94:1
at ModuleJob.run (node:internal/modules/esm/module_job:218:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:329:24)
at async loadESM (node:internal/process/esm_loader:28:7)
at async handleMainPromise (node:internal/modules/run_main:113:12)
```
Likely related to:
- https://github.com/matrixgpt/matrix-chatgpt-bot/issues/246
- https://github.com/matrixgpt/matrix-chatgpt-bot/pull/248
It can be tweaked around by overriding some default environment
variables (`roles/custom/matrix-bot-chatgpt/templates/env.j2`) in order to tweak them:
```
CHATGPT_MAX_CONTEXT_TOKENS=4097
CHATGPT_MAX_PROMPT_TOKENS=2500
```
This leads us to another issue:
```
node:internal/process/promises:289
triggerUncaughtException(err, true /* fromPromise */);
^
[Error: Failed to deserialize or serialize a JSON value missing field `version` at line 1 column 6704] {
code: 'GenericFailure'
}
Node.js v20.11.1
error Command failed with exit code 1.
```
... whatever that means.
* feat: auto-accept-invite module and docs
* fix: name typos and some forgot to adjust variables
* fix: accept only direct messages should work now and better wording
* changed: only_direct_messages variable naming
* feat: add logger, add synapse workers config
* Fix typo and add details about synapse-auto-acccept-invite
* Add newline at end of file
* Fix alignment
* Fix logger name for synapse_auto_accept_invite
The name of the logger needs to match the name of the Python module.
Ref: d673c67678/synapse_auto_accept_invite/__init__.py (L20)
* Add missing document start YAML annotation
* Remove trailing spaces
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Media didn't work before this patch, likely because this feature is broken:
> N.B. Discord now requires signed expiring download links, which means this solution no longer works. In the future, a more dynamic solution may be implemented where requests go to the bridge and the bridge and the bridge refetches the message if necessary.
Source: https://docs.mau.fi/bridges/go/discord/direct-media.html
Moreover, most users more likely don't want this behavior and would
prefer to keep a complete mirror of the media on Matrix, instead of
going through two 3rd party servers to fetch the media on demand.
The default config for the bridge
(https://github.com/mautrix/discord/blob/main/example-config.yaml)
actually does not enable it.
It seems like 4ed522e8fe
(https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3133)
lied to us as to what upstream does. Poor PR review lead to this
anti-feature making it into the playbook.
I've just tested Rocky Linux v9 and it seems to work.
I suppose the Docker situation
(https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300)
on RHEL v8 has improved, so it probably works too.
I see no reason AlmaLinux and other RHEL derivatives wouldn't work,
but I have neither tested them, nor have confirmation from others about
it.
It's mostly a matter of us being able to install:
- Docker, via https://github.com/geerlingguy/ansible-role-docker which
seems to support various distros
- a few other packages (systemd-timesyncd, etc).
The list of supported distros has been reordered alphabetically.
I've heard reports of SUSE Linux working well too, so it may also be added
if confirmed again.
Closes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/300
Fixup for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3017
This reverts 1cd82cf068 and also multiplies results by `1024`
so as to pass bytes to Synapse, not KB (as done before).
1cd82cf068 was correctly documenting what we were doing (passing KB values),
but that's incorrect.
Synapse's Config Conventions
(https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#config-conventions)
are supposed to clear it up, but they don't currently state what happens when you pass a plain number (without a unit suffix).
Thankfully, the source code tells us:
bc1db16086/synapse/config/_base.py (L181-L206)
> If an integer is provided it is treated as bytes and is unchanged.
>
> String byte sizes can have a suffix of ...
> No suffix is understood as a plain byte count.
We were previously passing strings, but that has been improved in 3d73ec887a.
Regardless, non-suffixed values seem to be treated as bytes by Synapse,
so this patch changes the variables to use bytes.
Moreover, we're moving from `matrix_synapse_memtotal_kb` to
`matrix_synapse_cache_size_calculations_memtotal_bytes` as working with
the base unit everywhere is preferrable.
Here, we also introduce 2 new variables to allow for the caps to be
tweaked:
- `matrix_synapse_cache_size_calculations_max_cache_memory_usage_cap_bytes`
- `matrix_synapse_cache_size_calculations_target_cache_memory_usage_cap_bytes`
We're casting everything it `int`, but since Jinja templates are
involved, these values end up as strings anyway.
Doing `| int | to_json` is good, but we should only cast numbers to
integer, not empty strings, as that (0) may be interpreted differently
by Synapse.
To turn of auto-tuning, one is possibly supposed to pass empty strings:
> This option defaults to off, enable it by providing values for the sub-options listed below.
It could be that `0` is also considered "no value provided", but I
haven't verified that.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3017
* Modify Synapse Cache Factor to use Auto Tune
Synapse has the ability to as it calls in its config auto tune caches.
This ability lets us set very high cache factors and then instead limit our resource use.
Defaults for this commit are 1/10th of what Element apparently runs for EMS stuff and matrix.org on Cache Factor and upstream documentation defaults for auto tune.
* Add vars to Synapse main.yml to control cache related config
This commit adds various cache related vars to main.yml for Synapse.
Some are auto tune and some are just adding explicit ways to control upstream vars.
* Updated Auto Tune figures
Autotuned figures have been bumped in consultation with other community members as to a reasonable level. Please note these defaults are more on the one of each workers side than they are on the monolith Side.
* Fix YML Error
The playbook is not happy with the previous state of this patch so this commit hopefully fixes it
* Add to_json to various Synapse tuning related configs
* Fix incorrect indication in homeserver.yaml.j2
* Minor cleanups
* Synapse Cache Autotuning Documentation
* Upgrade Synapse Cache Autotune to auto configure memory use
* Update Synapse Tuning docs to reflect automatic memory use configuration
* Fix Linting errors in synapses main.yml
* Rename variables for consistency (matrix_synapse_caches_autotuning_* -> matrix_synapse_cache_autotuning_*)
* Remove FIX ME comment about Synapse's `cache_autotuning`
`docs/maintenance-synapse.md` and `roles/custom/matrix-synapse/defaults/main.yml`
already contains documentation about these variables and the default values we set.
* Improve "Tuning caches and cache autotuning" documentation for Synapse
* Announce larger Synapse caches and cache auto-tuning
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Adds a Draupnir mention to the list and as for why we pull from Gnuxie its because that is the official source of docker images as Draupnir used to be Gnuxie/Draupnir before it moved to The Draupnir Project.
The path rule was not working because for federation fo work it needs several endpoints.
Two of them are not under /_matrix/federation :
- /_matrix/key
- /_matrix/media
`matrix_synapse_federation_port_enabled` is defined like this:
```
matrix_synapse_federation_port_enabled: "{{ matrix_synapse_federation_enabled or matrix_synapse_federation_port_openid_resource_required }}"
```
Previously, people that disabled federation, but needed the `openid`
listener were running without these federation-related labels.
In this patch, we're also dropping the `not matrix_synapse_workers_enabled` condition,
because.. none of the Matrix-related labels would be applied anyway when
workers are enabled, thanks to `matrix_synapse_container_labels_matrix_related_labels_enabled`.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3127
This is a break in backward-compatibility for people disabling
`index.html` creation via the playbook but are managing their static
website files in another way (AUX role, etc).
* Fix s3-storage migrate and shell: container needs attachment to postgres network also
* Connect to s3-storage-provider migrate to multiple networks in multiple steps
Multiple `--network` calls lead to:
> docker: Error response from daemon: Container cannot be connected to network endpoints: NETWORK_1 NETWORK_2.
* Connect to s3-storage-provider shell to multiple networks in multiple steps
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Previously, we only enabled metrics when the playbook was installing
Prometheus (as indicated by `prometheus_enabled`).
We are exposing metrics when `matrix_metrics_exposure_enabled` is
toggled to `true` though, but people need to toggle various
`_metrics_enabled` variables to make services actually serve metrics.
No more. If `matrix_metrics_exposure_enabled` is `true`, we'll
automatically enable metrics for all services.
* Update configuring-playbook-traefik.md
Added docu on how to host another server behind traefik.
* Added MASH and docker options
Added the link to mash and the compatibility adjustments.
Mentioned the prefered method with docker containers.
Some rephrasing to make clear, the intended guide ios for reverse proxying non-docker services.
* Improve wording in configuring-playbook-traefik.md
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Most addons live in the same network by default (matrix-addons) right now,
so this network would have usually been created by some other addon.
Howevre, if this is the only addon someone uses, it may have remained
uncreated causing a problem.
I believe `specialized-workers` is a better name than `room-workers`,
because when enabled, 4 different types of specialized workers are
created:
- Room workers
- Sync workers
- Client readers
- Federation readers
Only one of these is called room-workers.
In the future, more specialized workers may be added, making the
`room-workers` preset name an even poorer choice.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3100
Until now, the validation check would only get tripped up
if generic workers are used, combined with at least one EACH
other type of specialized workers.
This means that someone doing this:
```
matrix_synapse_workers_preset: one-of-each
matrix_synapse_workers_client_reader_workers_count: 5
```
.. would not have triggered this safety check.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3100
Hookshot wants a trailing slash for this route.
If we let Hookshot redirect, it goes to `/widgetapi/v1/static/`,
instead of `/hookshot/widgetapi/v1/static/`, so we take this matter into our
own hands.
Public URLs are like: `/hookshot/widgetapi/v1/static/`
.. which get translated to requests for: `/widgetapi/v1/static/`
Previously, we were stripping the whole `/hookshot/widgetapi` prefix,
which is wrong.
Most of these files were defining a service, usually toward the end.
These lines have been moved upward.
Some components (mautrix-signal, mautrix-gmessages, etc.) were defining
a service conditionally (only if metrics are exposed, etc). This was
causing issues like these in the Traefik logs:
> level=error msg="service \"matrix-mautrix-twitter\" error: port is missing" providerName=docker container=matrix-mautrix-twitter-..
This changes the behavior of
`matrix_playbook_migration_matrix_nginx_proxy_uninstallation_enabled`
and is against what we initially described in the changelog entry,
but I've discovered some problems when the `matrix-nginx-proxy` service
and container remain running. They need to go.
This allows people to not include the `matrix-conduit` or
`matrix-dendrite` roles in their custom playbook (based on our roles)
and still not have the playbook choke on variables from these roles
missing.
For getting rid of the `matrix-synapse` role in a similar way,
more work is likely necessary.
After some checking, it seems like there's `/_synapse/client/oidc`,
but no such thing as `/_synapse/oidc`.
I'm not sure why we've been reverse-proxying these paths for so long
(even in as far back as the `matrix-nginx-proxy` days), but it's time we
put a stop to it.
The OIDC docs have been simplified. There's no need to ask people to
expose the useless `/_synapse/oidc` endpoint. OIDC requires
`/_synapse/client/oidc` and `/_synapse/client` is exposed by default
already.
Traefik also serves an internal entrypoint that all addon services
(bridges, bots, etc.) depend on, so it makes sense to have it be
available early on. It is injected as a systemd `required` dependency
for all services, so it would have been pulled earlier anyway (despite
the priority). Nevertheless, it's better to make the playbook-defined
priotities for services match, so that services are explicitly asked to
start in a more correct order.
With these changes in place now, all "start service" tasks executed by
Ansible cause a "change", indicating that all these services are started
in the correct order and none of them is unintentionally started as a
dependency for another.
Issues and Pull Requests were not migrated to the new
organization/repository, so `matrix-org/synapse/pull` and
`matrix-org/synapse/issues` references were kept as-is.
`matrix-org/synapse-s3-storage-provider` references were also kept,
as that module still continues living under the `matrix-org` organization.
This patch mainly aims to change documentation-related things, not actual
usage in full yet. For polish that, another more comprehensive patch is coming later.
This moves the comments from being just in Jinja,
to actually ending up in the generated `labels` file,
which makes inspection of the final result easier.
Also, some new lines were added here and there to make labels
more legible.
The generated file may still include weird new-lines due to
various `if` statements yielding content or not, but that's not so ugly
anymore - now that we have proper start/end sections that are visible in
the final `labels` file.
The old variables still work. The global lets us avoid
auto-detection logic like we're currently doing for
`matrix_nginx_proxy_proxy_matrix_federation_api_enabled`.
In the future, we'd just be able to reference
`matrix_homeserver_federation_enabled` and know the up-to-date value
regardless of homeserver.
This was meant to serve as an intermediary for services needing to reach
the homeserver. It was used like that for a while in this
`bye-bye-nginx-proxy` branch, but was never actually public.
It has recently been superseded by homeserver-like services injecting
themselves into a new internal Traefik entrypoint
(see `matrix_playbook_internal_matrix_client_api_traefik_entrypoint_*`),
so `matrix-homeserver-proxy` is no longer necessary.
---
This is probably a good moment to share some benchmarks and reasons
for going with the internal Traefik entrypoint as opposed to this nginx
service.
1. (1400 rps) Directly to Synapse (`ab -n 1000 -c 100 http://matrix-synapse:8008/_matrix/client/versions`
2. (~900 rps) Via `matrix-homeserver-proxy` (nginx) proxying to Synapse (`ab -n 1000 -c 100 http://matrix-homeserver-proxy:8008/_matrix/client/versions`)
3. (~1200 rps) Via the new internal entrypoint of Traefik (`matrix-internal-matrix-client-api`) proxying to Synapse (`ab -n 1000 -c 100 http://matrix-traefik:8008/_matrix/client/versions`)
Besides Traefik being quicker for some reason, there are also other
benefits to not having this `matrix-homeserver-proxy` component:
- we can reuse what we have in terms of labels. Services can register a few extra labels on the new Traefik entrypoint
- we don't need services (like `matrix-media-repo`) to inject custom nginx configs into `matrix-homeserver-proxy`. They just need to register labels, like they do already.
- Traefik seems faster than nginx on this benchmark for some reason, which is a nice bonus
- no need to run one extra container (`matrix-homeserver-proxy`) and execute one extra Ansible role
- no need to maintain a setup where some people run the `matrix-homeserver-proxy` component (because they have route-stealing services like `matrix-media-repo` enabled) and others run an optimized setup without this component and everything needs to be rewired to talk to the homeserver directly. Now, everyone can go through Traefik and we can all run an identical setup
Downsides of the new Traefik entrypoint setup are that:
- all addon services that need to talk to the homeserver now depend on Traefik
- people running their own Traefik setup will be inconvenienced - they
need to manage one additional entrypoint
We'd be adding integration with an internal Traefik entrypoint
(`matrix_playbook_internal_matrix_client_api_traefik_entrypoint`),
so renaming helps disambiguate things.
There's no need for deperecation tasks, because the old names
have only been part of this `bye-bye-nginx-proxy` branch and not used by
anyone publicly.
This is a bit of a compatibility break.
The role was defaulting the Postgres password to `some-password` and we
auto-generate it now.
However, rebuilding both Postgres and this service should unify the
database credentials and the service configs to the new value.
This is an attempt at optimizing service startup.
The effect is most pronounced when many services are restarted one by one.
The systemd service manager role sometimes does this - for example when `just install-service synapse` runs.
In such cases, a 5-second delay for each Synapse worker service
(or other bridge/bot service that waits on the homeserver) quickly adds up to a lot.
When services are all stopped fully and then started, the effect is not so pronounced, because
`matrix-synapse.service` starts first and pulls all worker services (defined as `Wants=` for it).
Later on, when the systemd service manager role "starts" these worker services, they're started already.
Even if they had a 5-second wait each, it would have happened in parallel.
This reverts commit bf95ad2235.
This was a bad idea.
It's better to have people manually define the password.
Otherwise, `matrix_homeserver_generic_secret_key` changing some day in
the future would break the bot and one would have to figure out how to
reset its password manually.
Using an explicit password is more stable.
This probably never even worked anyway and was a leftover copy/paste
from some other role.
The docs (`docs/configuring-playbook-bridge-mautrix-wsproxy.md`) only
talk about `matrix_mautrix_wsproxy_hostname`, which was only used via
Traefik labels. The endpoint exposed via `matrix-nginx-proxy` (`/_matrix/wsproxy`)
hasn't been mentioned anywhere.
A lot of services are yet to be updated to start connecting to
`devture_postgres_container_network` as an additional network.
Many are already done, but I'll go through all the others later.
The latest tagged release (v0.1.3) does not pin any versions in its
Dockerfile and as such fails to build right now.
The `main` branch of rust-synapse-compress-state has already addressed
this and is buildable, but there's no tagged release yet.
Reported here: https://github.com/matrix-org/rust-synapse-compress-state/issues/134
Downsides: decreasing security slightly due to less networking isolation
Benefits:
- decreased complexity
- having a generically-named `matrix-addons` network we may use for other things now (client apps, etc.)
- not exhausting the container networks pool with 2 (or more) networks and using just 1
This also updates validation tasks and documentation, pointing to
variables in the matrix-synapse role which don't currently exist yet
(e.g. `matrix_synapse_container_labels_client_synapse_admin_api_enabled`).
These variables will be added soon, as Traefik labels are added to the
`matrix-synapse` role. At that point, the `matrix-synapse-reverse-proxy-companion` role
will be updated to also use them.
matrix-nginx-proxy is going away and this is one of the features it
offered.
This feature will have no equivalent in our new Traefik-only
setup, although it's possible to implement it manually by using
`matrix_client_element_container_labels_additional_labels`
This is still very far from usable.
Various bridges and bots are still talking to
`matrix-nginx-proxy` instead of the new `matrix-homeserver-proxy` role.
These services need to be reworked. While reworking them,
various cleanups are being done as well as adding Traefik-labels to
those that need them.
In nginx reverse-proxy, when the upstream server relies on SNI, the reverser-proxy may return 502 by follow error:
```
*10 SSL_do_handshake() failed (SSL: error:0A000410:SSL routines::sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 172.19.0.1, server: example.host, request: "GET /.well-known/matrix/client HTTP/2.0", upstream: "https://<ip>/.well-known/matrix/client", host: "<domain>"
```
This problem often arises when the upstream server is behind the CDN, setting `proxy_ssl_server_name` to `on` will solve it.
It seems like connectivity is problematic, even though the networks
appear to be configured correctly:
> [ioredis] Unhandled error event: Error: connect ECONNREFUSED 172.22.0.2:6739
> at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1595:16)
For now, I disable pointing the queue host to Redis to avoid it.
It should be investigated.
People who enable Hookshot's new experimental encryption may encounter
this also.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3042
Squashed based on the work done in https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3042
commit 49932b8f3c17c4c4db7a884658c42f9a8b0550ca
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:21:31 2023 +0200
Fix syntax in matrix-bridge-hookshot/tasks/reset_encryption.yml
Also, this task always does work and side-effects, so it should always report changes
(`changed_when: true`).
commit 6bdf7a9dcb73385313a1f34d52e27ad0cf95fb3e
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:12:41 2023 +0200
Add Hookshot validation task to ensure queue settings are set when encryption is enabled
commit 8c531b7971b5dfd15ca541b5072b3eb8237cdcf9
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:10:17 2023 +0200
Add missing variables rewiring in group_vars/matrix_servers for Hookshot
commit 7d26dabc2fe692f5e1236c0e250f85996f3fd0c2
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:08:19 2023 +0200
Add defaults for matrix_hookshot_queue_host and matrix_hookshot_queue_port
commit 74f91138c92f1d1b69eb973803b882849e31a259
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:06:17 2023 +0200
Fix syntax for connecting to additional networks for Hookshot
commit ca7b41f3f2d0c2900b2805294476f70e82461304
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:05:28 2023 +0200
Fix indentation and remove unnecessary if-statements
commit ac4a918d58fc76e7332446a65609b56c5e4da00c
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:04:44 2023 +0200
Add missing --network for Hookshot
This seems to have been removed by accident.
commit 6a81fa208fca28951fc131cbf33b95ec78748a40
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:02:47 2023 +0200
Make automatic Redis enabling safer, when Hookshot encryption enabled
If we ever default encryption to enabled for Hookshot, we only wish to force-enable Redis if Hookshot is actually enabled.
commit 75a8e0f2a6cbf1562cb99c68ad1f20e4d47735ed
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sat Dec 16 09:01:10 2023 +0200
Fix typo
commit 98ad182eaccc7ab457ead4e03cc0d4f2a525a47d
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:37:40 2023 +0100
Add defaults for Hookshot's encryption
commit 29fa9fab151f513908d3e45882003da107a63c93
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:35:11 2023 +0100
Improve wording of Hookshot's encryption section
commit 4f835e0560012754d7ce0b56619a97c68a297992
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:28:52 2023 +0100
use safer mount options for the container's files
commit 8c93327e25c5e6af2442c676d5f264d4051c80e2
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:26:01 2023 +0100
fix filename
commit 03a7bb6e7798dd95f7894311e4dd34dfa09f70fa
Merge: e55d7694 06047763
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:23:44 2023 +0100
Merge branch 'HarHarLinks/hookshot-encryption' of https://github.com/real-joshua/matrix-docker-ansible-deploy into HarHarLinks/hookshot-encryption
commit 06047763bbd427dde117c6635ac7301198571158
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:15:54 2023 +0100
Update roles/custom/matrix-bridge-hookshot/templates/config.yml.j2
change the if statement to not require a variable with a length > 0 and add a filter to json for the redis host
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
commit e55d769465bd299081464e68d34851729d42d5ff
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:13:50 2023 +0100
clarify that Redis is required, standardadise on Hookshot with an upper-case first letter for consistency
commit 66706e4535704deba63e5aa2102f324f9b14dae3
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 22:08:20 2023 +0100
Update roles/custom/matrix-bridge-hookshot/templates/config.yml.j2
fix for a typo
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
commit f6aaeb9a16f84409d31188e696885afed89fbdcc
Merge: e5d34002 869dd33f
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 00:22:34 2023 +0100
Merge branch 'master' into HarHarLinks/hookshot-encryption
commit e5d34002fd6c39c3e18df04e20d0c8b25475db78
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Fri Dec 15 00:09:27 2023 +0100
Add Jinja loop to allow adding multiple networks
commit 69f947782d6e072c3edc4ee4c7d5ccf69eccf3fd
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Thu Dec 14 23:52:41 2023 +0100
split if statements for the message queue and experimental encryption support into seperate statements
commit 4c13be1c89ffb1b06475c7da546f7956e67b36a1
Author: Joshua Hoffmann <joshua.hoffmann@b1-systems.de>
Date: Thu Dec 14 23:31:19 2023 +0100
change variable name per spantaleev's suggestion (https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2979#discussion_r1379015551)
commit 9905309aa9448f91297f8c7618bf62682eee2af7
Author: HarHarLinks <kim.brose@rwth-aachen.de>
Date: Wed Nov 1 16:14:04 2023 +0100
amend docs
commit 94abf2d5bde63919c6b5597f3142eea5fed73815
Author: HarHarLinks <kim.brose@rwth-aachen.de>
Date: Wed Nov 1 16:05:22 2023 +0100
draft encryption support for hookshot
* Remove mention of Android Element X being less feature complete than iOS version
Quoting upstream:
> Element X Android and Element X iOS apps are in a similar state.
>
> https://github.com/vector-im/element-x-android/issues/911
* Update configuring-playbook-sliding-sync-proxy.md
* Update matrix-domain.conf.j2
exchanged "^~" with "~" as a pattern matching in the location part.
I am very sure, that it only works using "~". I am not quite sure though, if this is the right way to do it, because "~" is probably more expensive than "^~"
the rewrite has to be behind the definition of the $backend. Otherwise nginx will fail to work. This is probably because "break" goes directly to the proxy_pass which uses $backend.
* Update matrix-domain.conf.j2
also change the order of "set $backend" and "rewrite" here in the 3pid registration section
* Update matrix-domain.conf.j2 - repeat v3_to_r0 rewrite in else-statement
as you said: repeat it for the else-case, where the ma1sd might be running on sans_container.
* Update matrix-domain.conf.j2 - corrected wrong variable
atrix_nginx_proxy_proxy_matrix_3pid_registration_v3_to_r0_redirect_enabled
is the right variable to check (twice) in the corresponding branch.
* matrix-domain.conf.j2 - fix-2954: change all whitespaces to tabs as you do it
---------
Co-authored-by: Tobias Küchel <t.kuechel@humboldt-ka.de>
Currently v3.0.0 tested with no issues.
So remove matrix_user_verification_service_docker_image from groups_vars.
/.npm must be writable or an error will be reported.
Hopefully, this makes it clearer that it's not just "public rooms"
that will now be exposed,
but rather "public rooms which are also published to the room directory".
This brings the values up-to-date as of the latest indexing run done
today. Due to a bug, the previous values were somewhat off.
The new numbers are different and actually demonstrate that the situation is
much worse than initially imagined.
It seems like with the default versioning detection strategy (`docker`),
the version is detected up to the hyphen:
> Renovate tries to follow the most common conventions that are used to tag Docker images.
> In particular, Renovate treats the text after the first hyphen as a type of platform/compatibility indicator.
Perhaps with `semver` would be more appropriate for this image.
More details in: https://docs.renovatebot.com/modules/versioning/
Without explicitly passing the `media_url` configuration,
Heisenbridge would try to guess it. It works most of the time,
but some people are experiencing trouble with it.
There's no need for wasteful work and for potential unreliability,
so we now configure the `media_url` explicitly.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2932
This reverts commit fd6daf3d24.
Looks like v1.2.5-1.8.2-2 supposedly offers Postgres v16 support,
but does not work well with it and will need additional work.
Rate limit docs had a issue due to the wrong request type by accident. This was not noticed due to both bots can work with rate limits. Synapse Admin links where also bugged but now fixed.
Many of these do depend on the Synapse master process (`matrix-synapse.service`),
so it makes sense to do it.
Furthermore, we're doing it so that one can stop the `matrix-synapse.service`
service and have systemd cascade this into stopping all the workers as well.
This is useful for easily stopping all of Synapse, so that Postgres
upgrades (`--tags=upgrade-postgres`) can happen cleanly.
Postgres upgrades currently stop `devture_postgres_systemd_services_to_stop_for_maintenance_list` which
includes Synapse, but stopping just the master process and leaving workers running is not safe enough and sometimes leads to errors like:
> ERROR: insert or update on table "event_forward_extremities" violates foreign key constraint "event_forward_extremities_event_id"
With this dependency in place, stopping `matrix-synapse.service` will stop all Synapse processes.
Draupnir moved its repo on github from the namespace of its maintainer Gnuxie to a newly created Github Organisation the-draupnir-project and this commit reflects this.
`spam_checker` has been deprecated for quite a while.
While it still probably works and while newer versions of
mjolnir-antispam still use it, we should switch to the new API.
The variable matrix_nginx_proxy_proxy_jitsi_additional_jvbs isn't
needed, as this information is already in the inventory.
This contribution is provided by GRNET S.A. (grnet.gr).
* Inital work, copeid from mautrix-amp PR
* Some fixes leftover code copeid over from whatsapp
* Got it to run and register
* Fixed service issue with docker image
* I now realize I need 2 roles wsproxy and imessage
* Got someting working, still rough
* Closer to working but still not working
* reverting ports
* Update main.yml
* Add matrix-nginx-proxy config for mautrix-wsproxy
* Changed
* Add back file
* fix for error hopefully
* Changed the the way nginx was recieved
* basically did not add anything ugh
* Added some arguments
* just trying stuff now
* Ugh i messed up port number
* Changed docs
* Change dns config
* changed generic secret key
* Testing new nginx proxy
* test
* Fix linting errors
* Add mautrix syncproxy to wsproxy for Android SMS
* WIP
* Move wsproxy to custom
* Squashed commit of the following:
commit 943189a9aa
Merge: 4a229d68f5a09f30
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Nov 13 08:54:32 2022 +0200
Merge pull request #2259 from throny/patch-3
warn users about upgrading to pg15 when using borg
commit 4a229d6870
Merge: 9b326e08c68def08
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Nov 13 08:53:13 2022 +0200
Merge pull request #2260 from etkecc/patch-117
Update ntfy 1.28.0 -> 1.29.0
commit f5a09f30b7
Author: throny <m.throne12@gmail.com>
Date: Sat Nov 12 23:48:57 2022 +0100
Update maintenance-postgres.md
commit b12cdbd99d
Author: throny <m.throne12@gmail.com>
Date: Sat Nov 12 23:40:46 2022 +0100
Update maintenance-postgres.md
commit c68def0809
Author: Aine <97398200+etkecc@users.noreply.github.com>
Date: Sat Nov 12 22:01:31 2022 +0000
Update ntfy 1.28.0 -> 1.29.0
commit adbc09f152
Author: throny <m.throne12@gmail.com>
Date: Sat Nov 12 11:20:43 2022 +0100
warn users about upgrading to pg15 when using borg
* Fix linting errors
* Cleanup after merge
* Correct outdated variable names
* Enable both Android and iMessage with wsproxy
* Restructure wsproxy service defs and nginx config
* Fix linter errors
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Fix comments for documentation, volumes and ports
* Correct mount syntax
* Complete network and traefik support for wsproxy
* Remove wsproxy data_path
* Fix wsproxy service definitions
* Actually include syncproxy service
* Remove wsproxy PathPrefix, it needs a subdomain
There's no setting in the iMessage bridge that allows a path.
Also don't bind port by default, wsproxy has no TLS.
Syncproxy should never expose a port, it's only internal.
---------
Co-authored-by: hanthor <jreilly112@gmail.com>
Co-authored-by: Miguel Alatzar <miguel@natrx.io>
Co-authored-by: Shreyas Ajjarapu <github.tzarina@aleeas.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This is backward-compatible with what we had before. We're not changing
the SSL mode - just making it configurable.
Most components are defaulting to `sslmode=disable`, while some
(`matrix-bot-matrix-reminder-bot` and others) do not specify an `sslmode` at all.
We're making sslmode configurable, because certain external Postgres
servers may be configured to require SSL encryption.
In such cases `sslmode=disable` does not work and needs to be changed to
`sslmode=require` or something else (`verify-ca`, `verify-full`, etc).
variable need to be named:
matrix_bot_matrix_registration_bot_bot_password
and not:
matrix_bot_matrix_registration_bot_password
Dont know if it need fixed in every rule or just change the docs
* intial commit
* changed
* Reorderd
* merge old changes
* added changes to matrix_servers
* Remove duplicate discord
* Update main.yml
* added google message to configuring-playbook.md
* Changed docs to add new changes
* Changed bug?
* Removed problem j2 values
* Rename a service files
* change how password hash string
* Changed port number
* Change how the local part works
* Revert "Merge pull request #8 from shreyasajj/wsproxy"
This reverts commit bb1b8fc67ca39f63ca77e70077be99cb2b32c4de, reversing
changes made to cce6ba5f9d74f89172488afc8b1ef124031de8c1.
---------
Co-authored-by: Shreyas Ajjarapu <github.tzarina@aleeas.com>
Making the group match the Ansible task tags allows people to do `just install-service matrix-media-repo` and have that trigger both `--tags=matrix-media-repo` and also restart just that single group (`matrix-media-repo`).
I was very surprised by the fact that a rather important configuration for coturn was "hidden" in the Hosts file, but not mentioned here.
Therefore my suggestion is to explicitly mention it here, as I believe that is that natural for people to look.
Some time ago a "playbooks" subdirectory had been created and setup.yml
had been moved there (as matrix.yml), together with the new
jitsi_jvb.yml. However, jitsi_jvb.yml wouldn't work at all, unless a
symbolic link to it was created from the root directory. A symbolic link
setup.yml for playbooks/matrix.yml had already been created and
committed.
This seems to indicate that the developers thought they should place all
playbooks in a subdirectory, but when this didn't work, they linked to
one of them, leaving the other one inoperative. We fix this by moving
the playbooks to the root directory. This works, and the pollution of
the root directory is not too bad since it's only two playbooks.
We also change the mode of setup.yml to 644 (it had inexplicably changed
to 755 in 9735a2f600).
This contribution is provided by GRNET S.A. (grnet.gr).
This was mostly affecting the stream writer (events) worker, which was
being reported as unhealthy. It wasn't causing any issues, but it just
looked odd and was confusing people.
As an alternative to hitting the regular `/health` healthcheck route (on
the "client" API which this stream writer does not expose),
we may have went for hitting some "replication" API endpoint instead.
This is more complicated and likely unnecessary.
Previously `just install-service buscarron` would not fully work,
because:
- the systemd services were indeed tagged with `buscarron`
- however, the actual installation tasks are not
`install-buscarron`/`setup-buscarron`, but rather
`install-bot-buscarron`/`setup-bot-buscarron`
Services are now tagged with the `bot-` prefix to match the tags.
Related to https://github.com/matrix-org/synapse/pull/15491
This doesn't hurt to be done early on, while still on Synapse v1.83.0.
We'll be able to remove the `worker_replication_*` settings later,
when Synapse v1.84.0 gets released and starts making use of the new
`main` instance in the instance map instead of looking at the
`worker_replication_*` settings.
These roles now obey
`devture_systemd_docker_base_container_image_pull_method` and `devture_systemd_docker_base_container_network_creation_method`
and can work on systems which don't have the Docker SDK for Python
installed by avoiding the various Ansible Docker modules and using raw
`docker` commands for pulling images and creating networks.
This change adds a section that lets the reader know that it is possible to enable synapse metrics and references the relevant documentation.
It aims to be short and concise, leaving the specifics to the referenced documentation, while still giving the reader a good idea of what it is and what it is for.
This way, something like `just install-service postgres` will
definitely do a `restart` and not a `stop` + `start` (which may leave
dependant services stopped).
This has potentially been addressed by
7acb5f4b85
as well.
With this change, all dependency roles are downloaded
using the same mechanism (git), which makes life simpler for tools like
https://gitlab.com/etke.cc/int/agru
It's not strictly required yet, but certain versions of Ansible display warnings
if passlib is missing. The non-passlib crypto usage is deprecated, so
passlib will become a requirement in newer Ansible versions. It's only a
matter of time.
It should be noted that this cannot be used for the initial install
of services which require a database or have other dependencies.
Those would typically need to invoke the playbook with
`--tags=install-postgres,install-SERVICE`, etc.
The purpose of this shortcut is to easily rebuild and restart
a single serice subsequently. For those cases, often times there's no need to
reinitialize the database and other components and simply running a
single component's tasks is enough.
This allows people to try out the new Element X clients, which need to
run against the sliding-sync proxy (https://github.com/matrix-org/sliding-sync).
Supersedes https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2515
The code is based on the existing PR (#2515), but heavily reworked. Major changes:
- lots of internal refactoring and variable renaming
- fixed self-building to support non-amd64 architectures
- changed to talk to the homeserver locally, over the container network (not
publicly)
- no more matrix-nginx-proxy support due to complexity (see below)
- no more `matrix_server_fqn_sliding_sync_proxy` in favor of
`matrix_sliding_sync_hostname` and `matrix_sliding_sync_path_prefix`
- runs on `matrix.DOMAIN/sliding-sync` by default, so it can tried
easily without having to create new DNS records
The variable was necessary when multiple playbooks could have
potentially tried to manage a shared `devture-traefik.serivce` systemd service
and shared `/devture-traefik` directory.
Since adcc6d9723, we use our own `/matrix/traefik`
(`matrix-traefik.service`) installation and no conflicts can arise.
It's safe to always enable the role, just like we do with all the other roles.
The migration is automatic. Existing users should experience a bit of
downtime until the playbook runs to completion, but don't need to do
anything manually.
This change is provoked by https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2535
While my statements there ("Traefik is a shared component among
sibling/related playbooks and should retain its global
non-matrix-prefixed name and path") do make sense, there's another point
of view as well.
With the addition of docker-socket-proxy support in bf2b540807,
we potentially introduced another non-`matrix-`-prefixed systemd service
and global path (`/devture-container-socket-proxy`). It would have
started to become messy.
Traefik always being called `devture-traefik.service` and using the `/devture-traefik` path
has the following downsides:
- different playbooks may write to the same place, unintentionally,
before you disable the Traefik role in some of them.
If each playbook manages its own installation, no such conflicts
arise and you'll learn about the conflict when one of them starts its
Traefik service and fails because the ports are already in use
- the data is scattered - backing up `/matrix` is no longer enough when
some stuff lives in `/devture-traefik` or `/devture-container-socket-proxy` as well;
similarly, deleting `/matrix` is no longer enough to clean up
For this reason, the Traefik instance managed by this playbook
will now be called `matrix-traefik` and live under `/matrix/traefik`.
This also makes it obvious to users running multiple playbooks, which
Traefik instance (powered by which playbook) is the active one.
Previously, you'd look at `devture-traefik.service` and wonder which
role was managing it.
* healthchecks.io integration
* mutex on forwarding messages into thread
* fix in prefixes handling
* send error messages as thread reply when possible
We don't need these 2 roughly-the-same settings related to the
traefik-certs-dumper role.
For Traefik, it makes sense, because it's a component used by the
various related playbooks and they could step onto each other's toes
if the role is enabled, but Traefik is disabled (in that case, uninstall
tasks will run).
As for Traefik certs dumper, the other related playbooks don't have it,
so there's no conflict. Even if they used it, each one would use its own
instance (different `devture_traefik_certs_dumper_identifier`), so there
wouldn't be a conflict and uninstall tasks can run without any danger.
This allows people wishing to change or unset the resolver,
to have a single variable which they can toggle.
Unsetting the resolver is useful for using your own certificates
(not coming from a certificate resolver).
This makes it consistent with the rest of the playbook:
- there's a default config which has various variables controlling
settings
- there's also an `_extension_yaml` variable, which lets you override it
The newly extracted role also has native Traefik support,
so we no longer need to rely on `matrix-nginx-proxy` for
reverse-proxying to Ntfy.
The new role uses port `80` inside the container (not `8080`, like
before), because that's the default assumption of the officially
published container image. Using a custom port (like `8080`), means the
default healthcheck command (which hardcodes port `80`) doesn't work.
Instead of fiddling to override the healthcheck command, we've decided
to stick to the default port instead. This only affects the
inside-the-container port, not any external ports.
The new role also supports adding the network ranges of the container's
multiple additional networks as "exempt hosts". Previously, only one
network's address range was added to "exempt hosts".
Previously, it had to go through matrix-nginx-proxy.
It's exposed to Traefik directly via container labels now
Serving at a path other than `/` doesn't work well yet.
We were mounting our own configuration to
`/usr/share/nginx/html/config.json`, which is a symlink to
`/tmp/config.json`. So we effectively mount our file to
`/tmp/config.json`.
When starting:
- if Hydrogen sees a `CONFIG_OVERRIDE` environment variable,
it will try to save it into our read-only config file and fail.
- if Hydrogen doesn't see a `CONFIG_OVERRIDE` environment variable (the
path we go through, because we don't pass such a variable),
it will try to copy its bundled configuration (`/config.json.bundled`)
to `/tmp/config.json`. Because our configuration is mounted as read-only, it will
fail.
In both cases, it will fail with:
> cp: can't create '/tmp/config.json': File exists
Source: 3720de36bb/docker/dynamic-config.sh
We work around this by mounting our configuration on top of the bundled
one (`/config.json.bundled`). We then let Hydrogen's startup script copy
it to `/tmp/config.json` (a tmpfs we've mounted into the container) and use it from there.
* fix: only add element related entries to client well-known if element is enabled
* Fix matrix-base/defaults/main.yml syntax
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
We'd like to auto-enable traefik-certs-dumper for these setups.
`devture_traefik_certs_dumper_ssl_dir_path` will be empty though,
so the role's validation will point people in the right direction.
This gets us started on adding a Traefik role and hooking Traefik:
- directly to services which support Traefik - we only have a few of
these right now, but the list will grow
- to matrix-nginx-proxy for most services that integrate with
matrix-nginx-proxy right now
Traefik usage should be disabled by default for now and nothing should
change for people just yet.
Enabling these experiments requires additional configuration like this:
```yaml
devture_traefik_ssl_email_address: '.....'
matrix_playbook_traefik_role_enabled: true
matrix_playbook_traefik_labels_enabled: true
matrix_ssl_retrieval_method: none
matrix_nginx_proxy_https_enabled: false
matrix_nginx_proxy_container_http_host_bind_port: ''
matrix_nginx_proxy_container_federation_host_bind_port: ''
matrix_nginx_proxy_trust_forwarded_proto: true
matrix_nginx_proxy_x_forwarded_for: '$proxy_add_x_forwarded_for'
matrix_coturn_enabled: false
```
What currently works is:
reverse-proxying for all nginx-proxy based services **except** for the Matrix homeserver
(both Client-Server an Federation traffic for the homeserver don't work yet)
Switching from doing "post-start" loop hacks to running the container
in 3 steps: `create` + potentially connect to additional networks + `start`.
This way, the container would be connected to all its networks even at
the very beginning of its life.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2427
This just enables the endpoint, which is somewhat helpful, but not
really enough to scrape them. Ideally, we'd be injecting these targets
into the Prometheus scrape config too.
For now, registering targets with Prometheus is very manual
(`matrix_prometheus_scraper_postgres_enabled`, `matrix_prometheus_scraper_hookshot_enabled`, ..).
This should be redone - e.g. a new `matrix_prometheus_scrape_config_jobs_auto` variable,
which is dynamically built in `group_vars/matrix_servers`.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2427
`metrics_enabled` should only expose the metrics locally, on the
container network, so that a local Prometheus can consume them.
Exposing them publicly should be done via a separate toggle (`metrics_proxying_enabled`).
This is how all other roles work, so this makes these mautrix roles consistent with the rest.
This helps large deployments which need to open up thousands of ports
(matrix_coturn_turn_udp_min_port, matrix_coturn_turn_udp_min_port)
On a test VM, opening 1k ports takes 17 seconds for Docker to "publish"
all of these ports (setting up forwarding rules with the firewall, etc),
so service startup and shutdown take a long amount of time.
If host-networking is used, there's no need to open any ports at all
and startup/shutdown can be quick.
This container needs a writable $HOME, and will fail at startup if
there isn't one.
Provide one by pointing HOME to a path under the mounted /data
directory.
* Allow the mautrix whatsapp relaybot to be enable with a variable
This allows a user to enable the relaybot by setting a variable in
`vars.yml` in the same way that the mautrix signal relaybot is
configured.
* Correct default values for mautrix whatsapp relaybot variables
* Add documentation for using the relaybot with mautrix whatsapp
* Adjust variable names to better reflect what they do
* Set default variables properly and use to_json in template
selectattr() returns a generator object, an iterator. This leads to an exception later, lists can't concated to iterators, only to other lists. So '| list' converts the iterator to a list and the script runs happily.
This extends the collection with support for seamless authentication at the Jitsi server using Matrix OpenID.
1. New role for installing the [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service)
2. Changes to Jitsi role: Installing Jitsi Prosody Mods and configuring Jitsi Auth
3. Changes to Jitsi and nginx-proxy roles: Serving .well-known/element/jitsi from jitsi.DOMAIN
4. We updated the Jitsi documentation on authentication and added documentation for the user verification service.
Please note that This Mjolnir version bump technnically is missing some extra stuff that mjolnir claims we should do but it didnt work when i tried it and well my mjolnir deployment has been running this since release day almost and its fine. No errors in log that are unexpected. (Mjolnir throws errors in the log for anyone who wonders for various things that are fine. Like if a protection is off that is an error. Its due to how matrix-bot-lib works.)
Without these:
- `--tags=install-synapse` and `--tags=install-all` would be incomplete
and will not contain Synapse worker configuration
- `--tags=install-synapse-reverse-proxy-companion` and
`--tags=setup-synapse-reverse-proxy-companion` would not contain
Synapse worker configuration
* Changes to allow a user to set the max participants on a jitsi
conference
* changed var name from jitsi_max_participants to matrix_prosody_jitsi_max_participants
* add prometheus-nginxlog-exporter role
* Rename matrix_prometheus_nginxlog_exporter_container_url to matrix_prometheus_nginxlog_exporter_container_hostname
* avoid referencing variables from other roles, handover info using group_vars/matrix_servers
* fix: stop service when uninstalling
fix: typo
move available arch's into a var
fix: text
* fix: prometheus enabled condition
Co-authored-by: ikkemaniac <ikkemaniac@localhost>
Running with a user (like `matrix:matrix`) fails if Etherpad is enabled,
because `/matrix/etherpad` is owned by `matrix_etherpad_user_uid`/`matrix_etherpad_user_gid` (`5001:5001`).
The `matrix` user can't acccess the Etherpad directory for this reason
and Borgmatic fails when trying to make a backup.
There may be other things under `/matrix` which similarly use
non-`matrix:matrix` permissions.
Another workaround might have been to add `/matrix/etherpad` (and
potentially other things) to `matrix_backup_borg_location_exclude_patterns`, but:
- that means Etherpad won't be backed up - not great
- only excluding Etherpad may not be enough. There may be other files we
need to exclude as well
---
Running with `root` is still not enough though.
We need at least the `CAP_DAC_OVERRIDE` capability, or we won't be able to read the
`/etc/borgmatic.d/config.yaml` configuration file (owned by
`matrix:matrix` with `0640` permissions).
---
Additionally, it seems like the backup process tries to write to at least a few directories:
- `/root/.borgmatic`
- `/root/.ssh`
- `/root/.config`
> [Errno 30] Read-only file system: '/root/.borgmatic'
> Error while creating a backup.
> /etc/borgmatic.d/config.yaml: Error running configuration file
We either need to stop mounting the container filesystem as readonly
(remove `--read-only`) or to allow writing via a `tmpfs`.
I've gone the `tmpfs` route which seems to work.
In any case, the mounted source directories (`matrix_backup_borg_location_source_directories`)
are read-only regardless, so our actual source files are protected from unintentional changes.
Without this, it's a string and borg says:
> At 'hooks.postgresql_databases[INDEX_HERE].port': '5432' is not of type 'integer'
> /etc/borgmatic/config.yaml /etc/borgmatic.d /tmp/.config/borgmatic/config.yaml /tmp/.config/borgmatic.d: No valid configuration files found
.. and fails to do anything.
This role is usable on its own and it's not tied to Matrix, so
extracting it out into an independent role that we install via
ansible-galaxy makes sense.
This also fixes the confusion from the other day, where
`matrix_postgres_*` had to be renamed to `devture_postgres_*`
(unless it was about `matrix_postgres_backup_*`).
We now can safely say that ALL `matrix_postgres_*` variables need to be
renamed.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2305
More details about the new key type can be found here:
https://eff-certbot.readthedocs.io/en/stable/using.html#rsa-and-ecdsa-keys
Existing RSA-based keys will continue to renew as RSA until manual
action is taken. Example from the documentation above:
> certbot renew --key-type ecdsa --cert-name example.com --force-renewal
In the future, we may add a command which does this automatically for
all domains.
There was no need to add `synapse` to the list manually
and then add all other additional databases.
When the `synapse` database was the main database, this made sense.
Since a long time ago already, ALL databases are "additional" databases,
so the `synapse` database is part of that list.
We could additional add the main (`matrix`) database to this list,
but there's probably no point in backing that one up.
Tests were carried out like this:
- `virtualenv3 env`
- `./env/bin/pip install ansible==4.10.0 ansible-core==2.11.7`
- `./env/bin/ansible-playbook .....`
The lowest version of `ansible-core` available on PyPI right now is
2.11.0. That version has trouble with `ansible==4.0.0` though.
The errors we were hitting seemed to be resolved by others online by
using `ansible==4.10.0` instead, which has a minimum `ansible-core`
requirement of `2.11.7`, so that's what we went with.
Older versions of Ansible may work, but.. I'm having trouble
installing them and don't want to spend too much time on digging through
ancient versions and testing them out. People should just learn to run
up-to-date software.
* added dendrite captcha options
* added hcaptcha doc
* proper url
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update main.yml
* renamed captcha vars to new naming scheme
* change vars to new format
* Rename back some incorrect renamed variables
These variables are either not just part of the `client_api` subsection,
or are not even part of that section at all. They shouldn't have been
renamed in baaef2ed616e2645550d9
* Fix up naming inconsistencies
Some of these variables had been renamed in one place,
but not in other places, so it couldn't have worked that way.
* Add validation/deprecation for renamed Dendrite variables
Related to 4097898f885cf4c73, baaef2ed616e2645550, 68f4418092fa8ad
and a0b4a0ae6b2f1f18
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
- forego removing Docker images - it's not effective anyway, because it
only removes the last version.. which is a drop in the bucket, usually
- do not reload systemd - it's none of our business. `--tags=start`,
etc., handle this
- combine all uninstall tasks under a single block, which only runs if
we detect traces (a leftover systemd .service file) of the component.
If no such .service is detected, we skip them all. This may lead to
incorect cleanup in rare cases, but is good enough for the most part.
Ansible recently started showing warnings about `crypt` being
deprecated. If one installs `passlib`, the `password_hash` values that
are generated would be different by default. With this patch, we ensure
consistency regardless of which one is used.
After this patch, password hashes (and UUIDs derived from them) will
change once, but they should be stable after that.
These hashes changing is not a problem, because the playbook
changes all references to the new values. Changes are only a problem if
they're done partially and with different tools.
For example:
- `--tags=setup-COMPONENT` with `passlib`
- `--tags=setup-postgres` with `crypt` (no `passlib`)
If so, the Postgres database password's value will differ for the
configuration generated for `COMPONENT`.
The `rounds=` value is arbitrary. It doesn't matter what it is,
as long as it's different than the default for `crypt` (5000)
and the default for `passlib` for `sha512` (656000).
Source (https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_filters.html):
> To ensure idempotency, specify rounds to be neither crypt’s nor passlib’s default, which is 5000 for crypt and a variable value (535000 for sha256, 656000 for sha512) for passlib
* Exempt Matrix server from ntfy rate limit
Add the matrix fqdn and localhost to ntfy's exemption list.
Also allow all ntfy rate limits to be configured through Ansible
variables.
* Fix names and formatting
* fixes
* tabs not spaces
* Lint
* Use raw tags instead of bracket soup
We had checks to avoid stopping/deleting systemd services for workers
that used to exist and will continue to exist, but we were deleting
config files for workers each time.. Only to recreate them again later.
This lead to:
- too many misleading "changed" tasks
- too much unnecessary work
- potential failures during playbook execution possibly leaving the
system in a bad state (no worker config files)
We need this to control whether `('matrix-' + matrix_homeserver_implementation + '.service')`
would get injected into `devture_systemd_service_manager_services_list_auto`
This was useful when the order of these roles in relation to Synapse
mattered (when we were injecting stuff into Synapse variables during
runtime). This is no longer the case since 0ea7cb5d18, so all of
this can be removed.
These `init.yml` (now `inject_into_nginx_proxy.yml`) tasks do not need
to `always` run. They only need to run for `setup-all` and
`setup-nginx-proxy`. Unless we're dealing with these 2 tags, we can
spare ourselves a lot of work.
This patch also moves the `when` statement from `init.yml` into
`main.yml` in an effort to further optimize things by potentially
avoiding the extra file include.
These are not even caused by Archlinux, but by running buggy Ansible on old Ubuntu
while targeting modern servers (like Archlinux, but also others, ..).
We shouldn't employ ugly workarounds like this. We should tell people to
avoid running buggy Ansible or bad distros like Ubuntu, even.
- Tried to split the list of services into distinct categories
- Use tables instead of a list
- Dropped "optional" flag, as every service is now optional anyways
- Added links to the documentation where docs exist and were missing before
- Split "Amazon S3" entry into two entries (Goofys and synapse-s3-storage-provider)
- Moved note about not needing all services to the top of the section
* Enable location sharing in Element
* Update roles/custom/matrix-client-element/tasks/validate_config.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update roles/custom/matrix-client-element/tasks/setup_install.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Rename location sharing vars to be consistent with other vars
* Rename style.json to map_style.json
* Add m.tile_server section to /.well-known/matrix/client
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Add task to configure a standalone JVB on a different server
* add missing file
* set nginx config
* update prosody file and expose port 5222
* change variable name to server id
* formatting change
* use server id of jvb-1 for the main server
* adding documentation
* adding more jvbs
* rename variable
* revert file
* fix yaml error
* minor doc fixes
* renaming tags and introducing a common tag
* remove duplicates
* add mapping for jvb to hostname/ip
* missed a jvb_server
* Update roles/matrix-nginx-proxy/templates/nginx/conf.d/matrix-jitsi.conf.j2
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* PR review comments and additional documentation
* iterate on dict items
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update docs/configuring-playbook-jitsi.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* adding documentation around the xmpp setting
* add common after
* reduce the number of services during init of the additional jvb
* remove rogue i
* revert change to jitsi init as it's needed
* only run the jvb service on the additional jvb host
* updating docs
* reset default and add documentation about the websocket port
* fix issue rather merge with master
* add missing role introduced in master
* this role is required too
* Adding new jitsi jvb playbook, moving setup.yml to matrix.yml and creating soft link
* updating documentation
* revert accidental change to file
* add symlink back to roles to aid running of the jitsi playbook
* Remove extra space
* Delete useless playbooks/roles symlink
* Remove blank lines
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Jitsi control sentry dns using vars
* renaming variables
* Revert "renaming variables"
This reverts commit 4146c48f6a2e71d1b0d3f58c767aea1b2f4f789c.
* set to connection string or 0 to disable
* Update comments
* Use empty string for default Sentry DSN variables
Both should work identically, but an empty string seems better
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This fixes a regression since the change done in c1c152f7ac.
When another role (say `matrix-jitsi`) included `roles/custom/matrix-base/tasks/util/ensure_openssl_installed.yml`,
which then included `{{ role_path }}/tasks/util/ensure_openssl_installed_DISTRO.yml`,
that `role_path` variable would end up being the parent role
(`matrix-jitsi`) and not the `matrix-base` role, so we'd get a failure.
An alternative solution may have been to avoid using `role_path`, but
importing roles properly (like we've done in this patch) sounds like a better way.
Unfortunately, `import_role` fails if `tasks_from` is something like
`util/ensure_openssl_installed` (containing a `/`), so I had to move
these utils out of `util/`.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2228
With this change, trying to run the playbook should report an error that
looks like this:
> The offending line appears to be:
>
> # Most of the roles below are not distributed with the playbook, but downloaded separately using `ansible-galaxy` via the `make roles` command (see `Makefile`).
> - role: galaxy/com.devture.ansible.role.playbook_help
> ^ here
.. with that comment included, which might help some people who missed
the `make roles` part.
Improves https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2232
We no longer ask users to create Matrix user accounts for these bots:
- Postmoogle
- Honoroit
- Reminder Bot
Other bots and services (matrix-registration-bot, maubot, mjolnir,
Dimension, etc.) require an Access Token to run (not a password),
so this new role doesn't help for them.
It does help for the above bots though, and for defining your own
"initial user accounts" in the `matrix_user_creator_users_additional`
variable.
Dendrite uses a lot of databases, but a single (`dendrite`) role, which
leads to `matrix_postgres_import_roles_to_ignore` being something like
`['dendrite', 'dendrite', 'dendrite', ...]` needlessly.
This leads to weird regexes being generated for
`matrix_postgres_import_roles_ignore_regex`.
It's not that it hurts, but it just looks odd.
We were only reporting failures for when the async task didn't finish.
We also need to report a failure for when the task finished, but
returned a non-zero exit code.
This is more consistent with how we name variables. It's also less
confusing, especially given that we have `matrix_hookshot_feeds_pollTimeoutSeconds` as well.
This allows people to augment the Synapse image with custom tools and
addons without having to rebuild it from scratch.
If customizations are enabled, the playbook will build a new
`localhost/matrixdotorg/synapse:VERSION-customized` image
on top of the default one (`FROM matrixdotorg/synapse:VERSION`)
and with custom Dockerfile build steps.
For servers that self-build the Synapse image, the Synapse image will be
built first, before proceding to extend it the same way.
In the future, we'll also have easy to enable Dockerfile build steps
for modules that the playbook supports.
We don't like updating to untagged releases, but..
0.2.1 has some regression and upstream is not releasing 0.2.2 or 0.3.0
just yet, so we either need to downgrade to 0.2.0 or go `latest`.
We can hopefully switch back to a tagged release soon.
Related to https://github.com/mautrix/instagram/issues/56
On Debian 10 (buster) at least, while the Synapse systemd service unit
was referring to Goofys as "matrix-goofys" without a ".service" suffix,
systemd was ignoring the goofys dependency, starting Synapse before
Goofys. All other dependant units which work are using the ".service"
suffix.
This generally leads to the mount path goofys using having been
populated by Synapse before Goofys starts, causing it to fail due to the
mount target not being empty.
The fix seems to be to ensure that the Synapse service unit refers to
Goofys as "matrix-goofys.service".
This change causes the following two lines in
"/etc/systemd/system/matrix-synapse.service":
Requires=matrix-goofys
After=matrix-goofys
To be changed to:
Requires=matrix-goofys.service
After=matrix-goofys.service
* Make registration proxy independent of other roles, document
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Fix yml issues
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Remove undefined variable (as service HAS to be exposed
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Add registration endpint
Defines the registration endpoint that should be intercepted/forwarded to the proxy
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Add image name
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
This is consistent with what all other roles do. If someone includes a
role, the assumption is that they want its functionality enabled.
The playbook distribution then disables components via
`group_vars/matrix_servers`. We've always had `matrix_grafana_enabled: false`
there, so flipping the in-role `_enabled` flag to `true` does not change
anything for playbook users. Users who import the roles individually in
their own other playbooks (and who don't use `group_vars/matrix_servers`)
may observe a change in the defaults with this.
Using `matrix_synapse_*` variables within the `matrix-grafana` role
is not a good practice.
We now have a `matrix_grafana_default_home_dashboard_path` variable
with a good universal default value and we override it via
`group_vars/matrix_servers` based on enabled components, etc.
This is a better fix for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2133
We shouldn't be using it in the role (`tasks/setup.yml`) without
defining at least some default value in the role itself.
We've always had the override in `group_vars/matrix_servers`,
so the variable was essentially defined (at the playbook level), but
that's not the right way to do things.
* send emails in UTF-8 👋
* fix options descriptions
* add SMTP auth
* allow sending emails from your apps and scripts using postmoogle as email provider
Add two important informations:
- The `mbc` commands must be ran in the docker container
- Not using this method prevent from using encrypted rooms with the bot
The Service is now exposed by default on port 8585 and forwarded by nginx to the specified endpoint
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
This keeps the configuration cleaner and hopefully prevents odd issues
if Synapse (by any chance) happens to interpret `pusher_instances: []`
as "no pushers", instead of as "push from the master process".
I haven't confirmed what an empty pushers/federation-senders list means,
so it's safer to just avoid it.
As stream writer workers are also powered by the `generic_worker`
Synapse app, this necessitated that we provide means for distinguishing
between them and regular `generic_workers`.
I've also taken the time to optimize nginx configuration generation
(more Jinja2 macro usage, less duplication).
Worker names have also changed.
Workers are now named sequentially like this:
- `matrix-synapse-worker-0-generic`
- `matrix-synapse-worker-1-stream-writer-typing`
- `matrix-synapse-worker-2-pusher`
instead of `matrix-synapse-worker_generic_worker-18111` (indexed with a
port number).
People who modify `matrix_synapse_workers_enabled_list` directly will
need to adjust their configuration.
* Add construct for cactus comments role
* Adjust config files
* Add docker self build to defaults
* Adjust tasks
* Fix smaller syntax errors
* Fix env argument
* Add tmp path to allow container writing there
Background why I did this: https://docs.gunicorn.org/en/stable/settings.html#worker-tmp-dir
* Change port back to 5000 as not configurable in container
* Try to add appservice config file for synapse to use
* Inject appservice file
* Correct copied variable name
* Comment out unused app service file injection
would need mounting the appservice file to the synapse container i guess
* Move role before synapse to be able to inject during runtime
* Remove unused parts
* Change default user id to mirror official docs
* Add docs
* Update roles/matrix-cactus-comments/tasks/setup_install.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update roles/matrix-cactus-comments/templates/cactus_appservice.yaml.j2
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Generate secrets if necessary, adjust docs
* Rename cactusbot userid
* Shorten salt strings
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Use tmpfs instead of persistent mount
* Remove proxy option as it is nonsense
* Add download and serving of cc-client files
* Add documentation on client
* Clarify docs a bit
* Add nginx proxy to required services
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Use container address
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Correct comment of user id
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Use releases or local distributed client
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Move homeserver url to defaults
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Correct truth value
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Add documentation of variables
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Tabs vs. spaces
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Make nginx root configurable
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Complete ake nginx root configurable
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Fix file permission
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
* Fix lint errors
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
Signed-off-by: Julian-Samuel Gebühr <julian-samuel@gebuehr.net>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* appservice: add and use matrix_homeserver_* vars
* appservice: use the new vars
* Apply suggestions from code review
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
Related to https://github.com/jitsi/docker-jitsi-meet/issues/1377
Adding this doesn't really help though. `stable-7648-2` is broken
regardless. `stable-7648-3` is necessary to make it work.
We're already updated to `-3` anyway. This just adds the missing
environment variable for completeness.
* Fix bug that prevented user with external nginx from launch
The backslash was missing and prevented users from starting the bot
* Add necessary config for ext nginx to docs
* Add automatic config for ext nginx, adjust docs
* Remove unneeded and possibly puzzeling documentation
Looks like we've skipped a bunch of 0.8.x versions (up to 0.8.9)
and are jumping straight to 0.9.0.
This is untested. Judging by Dendrite's changelog, it shouldn't cause
any breakage though: https://github.com/matrix-org/dendrite/blob/v0.9.0/CHANGES.md
* Add example configuration for Caddy v2
Add a basic example how to get synapse-admin running behind Caddy v2 proxy.
* Improve working, fix typos
* Fix typos
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Auto trust new signal identities
from signald doku: when a remote key changes, set trust level to TRUSTED_UNVERIFIED instead of UNTRUSTED
I find it much more convenient when new identities are automatically recognized as trusted, as the process to do that manually is cumbersome.
Should this the default behavior, or should i add an option to configure this behavior?
* Added option to trust new signal identities
* Using env file
* Renamed variable
* Corrected typo
* Use fully-qualified Ansible module name
* removed option trust_new_keys
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* if variable to bind an exporter container to a host port is set, have matrix-domain.conf (nginx) support this
* manipulate some variables to account for just port numbers or 0.0.0.0 IPs
* Make sure to use the right variable in the init.yml files
* Update roles/matrix-prometheus-node-exporter/tasks/init.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Update roles/matrix-prometheus-postgres-exporter/tasks/init.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* remove extraneous variables and whitespace
Co-authored-by: Luca Bilke <luca@gmail.com>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* run the playbook on multiple hosts with different credentials with this script
* fix: add yaml missing document start "---"
* fix: *now really* allow this script to be run from any directory
* add about-note to examples/host.yml
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* improve ansible-all-hosts.sh related docs/configuring-playbook.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* fix typos :)
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This is what upstream uses and also what
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1977
used.
Initially, I wanted to make the prefix more unique, in case another
Kakaotalk bridge comes along, but.. it's probably on the new bridge to
come up with a unique puppet prefix, not on us now to override upstream
decisions.
Adds support for: https://src.miscworks.net/fair/matrix-appservice-kakaotalk
This is pretty similar to
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1977
which just appeared, but has mostly been done independently.
I've taken some inspiration and did some fixups based on that PR.
Thanks to https://github.com/hnarjis for taking the time to contribute!
Notable differences between this branch compared to that PR:
- better naming and documentation around the "configuration" variables
- no unnecessary (5 sec.) intentional delay when starting `matrix-appservice-kakaotalk-node.service`
- stores configuration in `config/`, not in `data/`
- passes configuration as read-only and starts the bridge with (`--no-update`) to ensure no changes are made to it
- starts containers more securely - with `matrix:matrix` user:group (not `root`) and
reduced capabilities (`--cap-drop=ALL`)
- uses `tcp` for communication between the "node" and the appservice (simpler than sharing unix sockets)
- `registration.yaml` which is closer to the one generated by `matrix-appservice-kakaotalk` (no `de.sorunome.msc2409.push_ephemeral` stuff, etc.)
- `registration.yaml` which is more customizable (customizable bot username and prefix for puppets - see `matrix_appservice_kakaotalk_appservice_bot_username` and `matrix_appservice_kakaotalk_user_prefix`)
- less fragile and more extensible bridge permissions configuration via `matrix_appservice_kakaotalk_bridge_permissions`. Doing `{% if matrix_admin %}` in the bridge configuration sometimes causes syntax problems (I hit some myself) and is not ideal. Other bridges should be redone as well.
- configurable command prefix for the bridge, instead of hardcoding `!kt` (see `matrix_appservice_kakaotalk_command_prefix`)
- logging that is more consistent with the rest of the playbook (console / journald only, no logging to files), as well as configurable log level (via `matrix_appservice_kakaotalk_logging_level`)
- somewhat more detailed documentation (`docs/configuring-playbook-bridge-appservice-kakaotalk.md`)
- removed some dead code (data relocation tasks from `tasks/setup_install.yml`, as well as likely unnecessary SQLite -> Postgres migration)
Not doing {% if matrix_admin %} checks in the YAML also fixes some issues
with indentation being incorrect sometimes.
This should be backward compatible, except for mautrix-signal's case
where `matrix_mautrix_signal_bridge_permissions` previously existed
as a string, not a dictionary. `tasks/validate_config.yml` will catch
the problem an even provide a quick fix.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1894
Because the configuration file is now mounted as readonly and maubot tries to update it on start,
we get this warning:
> Failed to create tempfile to write updated config to disk: [Errno 30] Read-only file system: '/config/tmpfa8vcb3y.yaml'
It doesn't seem to cause issues though.
Because the configuration is no longer overwritten on every bot start, each
next Ansible run should no longer overwrite it again and report a
"changed" task.
* Make interface hidden behind proxy by default
* Remove expose option and replace with http_bind_port
Reasoning: This is a similar binary trigger but allows to bin not on all interfaces
* Clarify maubot admin purpose
* Remove unnecessary edif
* Extend docs to prevent common misconceptions
* Make http_bind_port singular, do not allow multiple values
* Make optional again
Reasoning: setup_install.yml only runs on --tags=setup-all or on --tags=setup-bot-maubot.
If --tags=setup-nginx-proxy or similar commands are run, setup_install.yml will not run and the nginx configuration will be incomplete.
Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#var-naming
We don't really fix these, but just suppress them,
because they're like that intentionally.
We try to name variables in a way that is consistent with the
configuration key they control. If the upstream component uses
camelCase, we also need to include camelCase in the variable name.
Reference: https://ansible-lint.readthedocs.io/en/latest/default_rules/#git-latest
Our variable naming is not necessarily consistent across roles.
I've tried to follow the naming conventions of each individual role.
All new variables are suffixed with `_version`, but the prefix may be
somewhat different.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1931
This does 2 things:
- it fixes the syntax for `matrix_id`. Starting strings with `@` is
invalid YAML, so such strings need to be wrapped in single or double
quotes
- it makes use of the `matrix_domain` variable instead of hardcoding the
domain name. This should be more and mistake-proof (typos or people
mistaking their domain - matrix. vs base domain)
* Creating generic mautrix bridge doc
Not a huge fan of how it turned out at all, not sure how to make it better.
* Rename configuring-playbook-bridge-mautrix-Generic.md to configuring-playbook-bridges.md
* accepting suggested edits after rename mess
* Adding log level configuration
* Update docs/configuring-playbook-bridges.md
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
* Rename configuring-playbook-bridges.md to configuring-playbook-mautrix-bridges.md
Co-authored-by: ThellraAK <ThellraAK@pop-os.localdomain>
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
This commit adds a 'matrix-ntfy' role that runs Ntfy server in Docker with
simple configuration, and plumbing to add the role to the playbook.
TODO: documentation, self-check, database persistence.
`localhost` may resolve to `::1` on some IPv6-enabled systems, which will
not work, because we only potentially expose container ports on
`127.0.0.1` when nginx is disabled (`matrix_nginx_proxy_enabled: false`),
not on `::1`.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1914
Adding the defaults in addition to template, switching YOUR_DOMAIN to {{ matrix_domain }}, and giving example of the two combined, as the playbook gives a warning about things being defined twice, so only using the last one in the vars.yml
Copy/Pasting from docs/configuring-playbook-bridge-mautrix-facebook.md but with the relevant variable names changed to add turning on encryption and a puppet admin.
This shall indicate that the public url of maubot is here configured the same as matrix_server_fqn_matrix but this must not be the case.
In the config I used the matrix fqnd directly as this part of the config is directly bound to the homeserver we want to connect to (but can not use the internal)
Currently, Synapse workers ignore the X-Forwarded headers, which leads to internal Docker IP addresses randomly appearing in the users' device list.
This adds the `x_forwarded: true` option to the worker config, fixing the issue.
Source: https://github.com/matrix-org/synapse/blob/v1.59.0/docs/upgrade.md#deprecation-of-the-synapseappappservice-and-synapseappuser_dir-worker-application-types
As an alternative, we should probably find a way to run one or a few
more generic workers (which will handle appservice and user_dir stuff) and
update `homeserver.yaml` so that it would point to the name of these workers using
`notify_appservices_from_worker` and `update_user_directory_from_worker` options.
For now, this solves the deprecation, so we can have a peace of mind
going forward.
We're force-setting these worker counts to 0, so that we can clean up
existing homeservers which use these worker types. In the future, these
options will either be removed or repurposed (so that they transparently
create more generic workers that handle user_dir/appservice loads).
A clear and concise description of what the bug is.
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**
**To Reproduce**
@ -34,7 +34,7 @@ A clear and concise description of what you expected to happen.
**Ansible:**
**Ansible:**
If your problem appears to be with Ansible, tell us:
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`)
- what version of Ansible you're running (see `ansible --version`)
**Is your feature request related to a problem? Please describe.**
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
A clear and concise description of what the problem is. Ex. I'm always frustrated when […]
<!--
<!--
NOTE: When submitting feature requests, be aware that:
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.
-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.
NOTE: you can usually get more timely support and from more people by joining our Matrix room (also bridged to IRC). See the [Support section of our README](https://github.com/spantaleev/matrix-docker-ansible-deploy#support)
NOTE: our FAQ page is available at https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/faq.md. It contains a list of questions and answers about configuration, installation, troubleshooting, etc. Before creating a new issue, you are encouraged to have a look at it.
Also you can usually get more timely support and from more people by joining our Matrix room (also bridged to IRC). See the support section of our README.
-->
-->
**Playbook Configuration**:
**Playbook Configuration**:
@ -26,7 +28,7 @@ Make sure to remove any secret values before posting your vars.yml file publicly
**Ansible:**
**Ansible:**
If your problem appears to be with Ansible, tell us:
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`)
- what version of Ansible you're running (see `ansible --version`)
stale-issue-message:'This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days. To exempt the issue from being marked as stale again due to inactivity, add "confirmed" label.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity. If this issue is still reproduced, feel free to provide the issue with up-to-date information.'
stale-issue-label:'stale'
# Add this label to exempt the issue from being marked as stale due to inactivity
exempt-issue-labels:'confirmed'
# An allow-list of label(s) to only process the issues which contain one of these label(s).
stale-pr-message:'This PR is stale because it has not been provided with required information or its conflicts have not been fixed over a year. Remove stale label or this will be closed in 30 days. To exempt the PR from being marked as stale again due to inactivity, add "confirmed" label.'
close-pr-message:'This PR was closed because it has been stalled for 30 days with no activity.'
stale-pr-label:'stale'
# Add this label to exempt the PR from being marked as stale due to inactivity
exempt-pr-labels:'confirmed'
# An allow-list of label(s) to only process the PRs which contain one of these label(s).
any-of-pr-labels:'needs-info,needs-rebase'
# Use this to ignore updates such as comments (only to keep the PR alive by bumping)
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.
The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, our General Public Licenses are intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
Developers that use our General Public Licenses protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License which gives you legal permission to copy, distribute and/or modify the software.
A secondary benefit of defending all users' freedom is that improvements made in alternate versions of the program, if they receive widespread use, become available for other developers to incorporate. Many developers of free software are heartened and encouraged by the resulting cooperation. However, in the case of software used on network servers, this result may fail to come about. The GNU General Public License permits making a modified version and letting the public access it on a server without ever releasing its source code to the public.
The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU Affero General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this License. Each licensee is addressed as "you". "Licensees" and "recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based on the Program.
To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work.
A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The Corresponding Source for a work in source code form is that same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices".
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.
"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To "grant" such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
A patent license is "discriminatory" if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU Affero General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU Affero General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU Affero General Public License, you may choose any version ever published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future versions of the GNU Affero General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If your software can interact with users remotely through a computer network, you should also make sure that it provides a way for users to get its source. For example, if your program is a web application, its interface could display a "Source" link that leads users to an archive of the code. There are many ways you could offer source, and different solutions will be better for different programs; see section 13 for the specific requirements.
You should also get your employer (if you work as a programmer) or school, if any, to sign a "copyright disclaimer" for the program, if necessary. For more information on this, and how to apply and follow the GNU AGPL, see <http://www.gnu.org/licenses/>.
[](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
# Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker
## Purpose
## 🎯 Purpose
This [Ansible](https://www.ansible.com/) playbook is meant to help you run your own [Matrix](http://matrix.org/) homeserver, along with the [various services](#supported-services) related to that.
This [Ansible](https://www.ansible.com/) playbook is meant to help you run your own [Matrix](http://matrix.org/) homeserver, along with the [various services](#supported-services) related to that.
That is, it lets you join the Matrix network using your own `@<username>:<your-domain>` identifier, all hosted on your own server (see [prerequisites](docs/prerequisites.md)).
That is, it lets you join the Matrix network using your own user ID like `@alice:example.com`, all hosted on your own server (see [prerequisites](docs/prerequisites.md)).
We run all services in [Docker](https://www.docker.com/) containers (see [the container images we use](docs/container-images.md)), which lets us have a predictable and up-to-date setup, across multiple supported distros (see [prerequisites](docs/prerequisites.md)) and [architectures](docs/alternative-architectures.md) (x86/amd64 being recommended).
We run all [supported services](#-supported-services) in [Docker](https://www.docker.com/) containers (see [the container images we use](docs/container-images.md)), which lets us have a predictable and up-to-date setup, across multiple supported distros (see [prerequisites](docs/prerequisites.md)) and [architectures](docs/alternative-architectures.md) (x86/amd64 being recommended).
[Installation](docs/README.md) (upgrades) and some maintenance tasks are automated using [Ansible](https://www.ansible.com/) (see [our Ansible guide](docs/ansible.md)).
Installation (upgrades) and some maintenance tasks are automated using [Ansible](https://www.ansible.com/) (see [our Ansible guide](docs/ansible.md)).
## ☁ Self-hosting or Managed / SaaS
## Supported services
This Ansible playbook tries to make self-hosting and maintaining a Matrix server fairly easy (see [Getting started](#-getting-started)). Still, running any service smoothly requires knowledge, time and effort.
Using this playbook, you can get the following services configured on your server:
If you like the [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software) spirit of this Ansible playbook, but prefer to put the responsibility on someone else, you can also [get a managed Matrix server from etke.cc](https://etke.cc?utm_source=github&utm_medium=readme&utm_campaign=mdad) (both hosting and on-premises) - a service built on top of this Ansible playbook but with [additional components](https://etke.cc/help/extras/?utm_source=github&utm_medium=readme&utm_campaign=mdad) and [services](https://etke.cc/services/?utm_source=github&utm_medium=readme&utm_campaign=mdad) which all help you run a Matrix server with ease. Be advised that etke.cc operates on a subscription-based approach and there is no "just set up my server once and be done with it" option.
- (optional, default) a [Synapse](https://github.com/matrix-org/synapse) homeserver - storing your data and managing your presence in the [Matrix](http://matrix.org/) network
## 🚀 Getting started
- (optional) a [Dendrite](https://github.com/matrix-org/dendrite) homeserver - 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.
We have detailed documentation in the [docs/](./docs) directory - see the Table of Contents in the [documentation README](./docs/README.md).
- (optional) [Amazon S3](https://aws.amazon.com/s3/) storage for Synapse's content repository (`media_store`) files using [Goofys](https://github.com/kahing/goofys)
While the [list of supported services](#-supported-services) and documentation is very extensive, you don't need toread through everything. We recommend:
-(optional, default) [PostgreSQL](https://www.postgresql.org/) database for Synapse. [Using an external PostgreSQL server](docs/configuring-playbook-external-postgres.md) is also possible.
-Starting with the basics. You can always add/remove or tweak services later on.
-(optional, default) a [coturn](https://github.com/coturn/coturn) STUN/TURN server for WebRTC audio/video calls
-Following our installation guide. There are two guides available for beginners and advanced users:
- (optional, default) free [Let's Encrypt](https://letsencrypt.org/) SSL certificate, which secures the connection to the Synapse server and the Element web UI
- ⚡ **[Quick start](./docs/quick-start.md) (for beginners)**: this is recommended for those who do not have an existing Matrix server and want to start quickly with "opinionated defaults".
- (optional, default) an [Element](https://app.element.io/) ([formerly Riot](https://element.io/previously-riot)) web UI, which is configured to connect to your own Synapse server by default
- **Full installation guide (for advanced users)**: if you need to import an existing Matrix server's data into the new server or want to learn more while setting up the server, follow this guide by starting with the **[Prerequisites](./docs/prerequisites.md)** documentation page.
- (optional) a [ma1sd](https://github.com/ma1uta/ma1sd) Matrix Identity server
If you experience an issue on configuring the playbook, setting up your server, maintaining services on it, etc., please take a look at our [FAQ](./docs/faq.md). If you cannot find an answer to your question, feel free to ask for [help and support](#-support).
- (optional, default) an [Exim](https://www.exim.org/) mail server, through which all Matrix services send outgoing email (can be configured to relay through another SMTP server)
## ✔ Supported services
- (optional, default) an [nginx](http://nginx.org/) web server, listening on ports 80 and 443 - standing in front of all the other services. Using your own webserver [is possible](docs/configuring-playbook-own-webserver.md)
Using this playbook, you can get the following list of services configured on your server. Basically, this playbook aims to get you up-and-running with all the necessities around Matrix, without you having to do anything else.
- (optional, advanced) the [matrix-synapse-rest-auth](https://github.com/ma1uta/matrix-synapse-rest-password-provider) REST authentication password provider module
**Notes**:
-(optional, advanced) the [matrix-synapse-shared-secret-auth](https://github.com/devture/matrix-synapse-shared-secret-auth) password provider module
-The list below is exhaustive. It includes optional or even some advanced components that you will most likely not need. Sticking with the defaults (which install a subset of the above components) is the best choice, especially for a new installation. You can always re-run the playbook later to add or remove components.
-(optional, advanced) the [matrix-synapse-ldap3](https://github.com/matrix-org/matrix-synapse-ldap3) LDAP Auth password provider module
-Deprecated or unmaintained services are not listed. You can find documentations for them [here](docs/configuring-playbook.md#deprecated--unmaintained--removed-services).
- (optional, advanced) the [synapse-simple-antispam](https://github.com/t2bot/synapse-simple-antispam) spam checker module
### Homeserver
- (optional, advanced) the [Matrix Corporal](https://github.com/devture/matrix-corporal) reconciliator and gateway for a managed Matrix server
The homeserver is the backbone of your Matrix system. Choose one from the following list.
- (optional) the [mautrix-telegram](https://github.com/mautrix/telegram) bridge for bridging your Matrix server to [Telegram](https://telegram.org/)
| Name | Default? | Description | Documentation |
| ---- | -------- | ----------- | ------------- |
| [Synapse](https://github.com/element-hq/synapse) | ✅ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network | [Link](docs/configuring-playbook-synapse.md) |
| [Conduit](https://conduit.rs) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Conduit is a lightweight open-source server implementation of the Matrix Specification with a focus on easy setup and low system requirements | [Link](docs/configuring-playbook-conduit.md) |
| [conduwuit](https://conduwuit.puppyirl.gay/) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. conduwuit is a fork of Conduit. | [Link](docs/configuring-playbook-conduwuit.md) |
| [continuwuity](https://continuwuity.org) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. continuwuity is a continuation of conduwuit. | [Link](docs/configuring-playbook-continuwuity.md) |
| [Dendrite](https://github.com/element-hq/dendrite) | ❌ | Storing your data and managing your presence in the [Matrix](http://matrix.org/) network. Dendrite is a second-generation Matrix homeserver written in Go, an alternative to Synapse. | [Link](docs/configuring-playbook-dendrite.md) |
- (optional) the [mautrix-whatsapp](https://github.com/mautrix/whatsapp) bridge for bridging your Matrix server to [WhatsApp](https://www.whatsapp.com/)
### Clients
- (optional) the [mautrix-facebook](https://github.com/mautrix/facebook) bridge for bridging your Matrix server to [Facebook](https://facebook.com/)
Web clients for Matrix that you can host on your own domains.
- (optional) the [mautrix-twitter](https://github.com/mautrix/twitter) bridge for bridging your Matrix server to [Twitter](https://twitter.com/)
| Name | Default? | Description | Documentation |
| ---- | -------- | ----------- | ------------- |
| [Element Web](https://github.com/element-hq/element-web) | ✅ | Default Matrix web client, configured to connect to your own Synapse server | [Link](docs/configuring-playbook-client-element-web.md) |
| [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) |
- (optional) the [mautrix-hangouts](https://github.com/mautrix/hangouts) bridge for bridging your Matrix server to [Google Hangouts](https://en.wikipedia.org/wiki/Google_Hangouts)
### Server Components
- (optional) the [mautrix-googlechat](https://github.com/mautrix/googlechat) bridge for bridging your Matrix server to [Google Chat](https://en.wikipedia.org/wiki/Google_Chat)
Services that run on the server to make the various parts of your installation work.
- (optional) the [mautrix-instagram](https://github.com/mautrix/instagram) bridge for bridging your Matrix server to [Instagram](https://instagram.com/)
| 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](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) |
- (optional) the [mautrix-signal](https://github.com/mautrix/signal) bridge for bridging your Matrix server to [Signal](https://www.signal.org/)
### Authentication
- (optional) the [beeper-linkedin](https://gitlab.com/beeper/linkedin) bridge for bridging your Matrix server to [LinkedIn](https://www.linkedin.com/)
Extend and modify how users are authenticated on your homeserver.
- (optional) the [matrix-appservice-irc](https://github.com/matrix-org/matrix-appservice-irc) bridge for bridging your Matrix server to [IRC](https://wikipedia.org/wiki/Internet_Relay_Chat)
| [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) |
- (optional) the [matrix-appservice-discord](https://github.com/Half-Shot/matrix-appservice-discord) bridge for bridging your Matrix server to [Discord](https://discordapp.com/)
### File Storage
- (optional) the [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) bridge for bridging your Matrix server to [Slack](https://slack.com/)
Use alternative file storage to the default `media_store` folder.
- (optional) the [matrix-appservice-webhooks](https://github.com/turt2live/matrix-appservice-webhooks) bridge for slack compatible webhooks ([ConcourseCI](https://concourse-ci.org/), [Slack](https://slack.com/) etc. pp.)
| [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) |
- (optional) the [matrix-hookshot](https://github.com/Half-Shot/matrix-hookshot) bridge for bridging Matrix to generic webhooks and multiple project management services, such as GitHub, GitLab, Figma, and Jira in particular
### Bridges
- (optional) the [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) for bridging your Matrix server to SMS - see [docs/configuring-playbook-bridge-matrix-bridge-sms.md](docs/configuring-playbook-bridge-matrix-bridge-sms.md) for setup documentation
Bridges can be used to connect your Matrix installation with third-party communication networks.
- (optional) the [Heisenbridge](https://github.com/hifi/heisenbridge) for bridging your Matrix server to IRC bouncer-style - see [docs/configuring-playbook-bridge-heisenbridge.md](docs/configuring-playbook-bridge-heisenbridge.md) for setup documentation
| Name | Default? | Description | Documentation |
| ---- | -------- | ----------- | ------------- |
- (optional) the [mx-puppet-skype](https://hub.docker.com/r/sorunome/mx-puppet-skype) for bridging your Matrix server to [Skype](https://www.skype.com) - see [docs/configuring-playbook-bridge-mx-puppet-skype.md](docs/configuring-playbook-bridge-mx-puppet-skype.md) for setup documentation
- (optional) the [mx-puppet-slack](https://hub.docker.com/r/sorunome/mx-puppet-slack) for bridging your Matrix server to [Slack](https://slack.com) - see [docs/configuring-playbook-bridge-mx-puppet-slack.md](docs/configuring-playbook-bridge-mx-puppet-slack.md) for setup documentation
- (optional) the [mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram) bridge for Instagram-DMs ([Instagram](https://www.instagram.com/)) - see [docs/configuring-playbook-bridge-mx-puppet-instagram.md](docs/configuring-playbook-bridge-mx-puppet-instagram.md) for setup documentation
| [mautrix-wsproxy](https://github.com/mautrix/wsproxy) | ❌ | Bridge to Android SMS or Apple iMessage | [Link](docs/configuring-playbook-bridge-mautrix-wsproxy.md) |
- (optional) the [mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter) bridge for Twitter-DMs ([Twitter](https://twitter.com/))- see [docs/configuring-playbook-bridge-mx-puppet-twitter.md](docs/configuring-playbook-bridge-mx-puppet-twitter.md) for setup documentation
- (optional) the [mx-puppet-discord](https://github.com/matrix-discord/mx-puppet-discord) bridge for [Discord](https://discordapp.com/) - see [docs/configuring-playbook-bridge-mx-puppet-discord.md](docs/configuring-playbook-bridge-mx-puppet-discord.md) for setup documentation
| [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) |
- (optional) the [mx-puppet-groupme](https://gitlab.com/robintown/mx-puppet-groupme) bridge for [GroupMe](https://groupme.com/) - see [docs/configuring-playbook-bridge-mx-puppet-groupme.md](docs/configuring-playbook-bridge-mx-puppet-groupme.md) for setup documentation
- (optional) the [mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) bridge for [Steam](https://steamapp.com/) - see [docs/configuring-playbook-bridge-mx-puppet-steam.md](docs/configuring-playbook-bridge-mx-puppet-steam.md) for setup documentation
- (optional) [Email2Matrix](https://github.com/devture/email2matrix) for relaying email messages to Matrix rooms - see [docs/configuring-playbook-email2matrix.md](docs/configuring-playbook-email2matrix.md) for setup documentation
- (optional) [Dimension](https://github.com/turt2live/matrix-dimension), an open source integrations manager for matrix clients - see [docs/configuring-playbook-dimension.md](docs/configuring-playbook-dimension.md) for setup documentation
| [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) | ❌ | Bridge for generic webhooks and multiple project management services, such as GitHub, GitLab, Figma, and Jira in particular | [Link](docs/configuring-playbook-bridge-hookshot.md) |
- (optional) [Etherpad](https://etherpad.org), an open source collaborative text editor - see [docs/configuring-playbook-etherpad.md](docs/configuring-playbook-etherpad.md) for setup documentation
- (optional) [Jitsi](https://jitsi.org/), an open source video-conferencing platform - see [docs/configuring-playbook-jitsi.md](docs/configuring-playbook-jitsi.md) for setup documentation
- (optional) [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) for scheduling one-off & recurring reminders and alarms - see [docs/configuring-playbook-bot-matrix-reminder-bot.md](docs/configuring-playbook-bot-matrix-reminder-bot.md) for setup documentation
- (optional) [Go-NEB](https://github.com/matrix-org/go-neb) multi functional bot written in Go - see [docs/configuring-playbook-bot-go-neb.md](docs/configuring-playbook-bot-go-neb.md) for setup documentation
- (optional) [Mjolnir](https://github.com/matrix-org/mjolnir), a moderation tool for Matrix - see [docs/configuring-playbook-bot-mjolnir.md](docs/configuring-playbook-bot-mjolnir.md) for setup documentation
### Bots
- (optional) [synapse-admin](https://github.com/Awesome-Technologies/synapse-admin), a web UI tool for administrating users and rooms on your Matrix server - see [docs/configuring-playbook-synapse-admin.md](docs/configuring-playbook-synapse-admin.md) for setup documentation
Bots provide various additional functionality to your installation.
- (optional) [matrix-registration](https://github.com/ZerataX/matrix-registration), a simple python application to have a token based matrix registration - see [docs/configuring-playbook-matrix-registration.md](docs/configuring-playbook-matrix-registration.md) for setup documentation
| Name | Default? | Description | Documentation |
- (optional) 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 - see [Enabling metrics and graphs (Prometheus, Grafana) for your Matrix server](docs/configuring-playbook-prometheus-grafana.md) for setup documentation
| ---- | -------- | ----------- | ------------- |
| [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) |
- (optional) the [Sygnal](https://github.com/matrix-org/sygnal) push gateway - see [Setting up the Sygnal push gateway](docs/configuring-playbook-sygnal.md) for setup documentation
| [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) |
- (optional) the [Hydrogen](https://github.com/vector-im/hydrogen-web) web client - see [docs/configuring-playbook-client-hydrogen.md](docs/configuring-playbook-client-hydrogen.md) for setup documentation
- (optional) the [Cinny](https://github.com/ajbura/cinny) web client - see [docs/configuring-playbook-client-cinny.md](docs/configuring-playbook-client-cinny.md) for setup documentation
| [Draupnir](https://github.com/the-draupnir-project/Draupnir) | ❌ | Moderation tool for Matrix (Fork of Mjolnir) | [Link](docs/configuring-playbook-bot-draupnir.md) (for [appservice mode](docs/configuring-playbook-appservice-draupnir-for-all.md))|
- (optional) the [Borg](https://borgbackup.org) backup - see [docs/configuring-playbook-backup-borg.md](docs/configuring-playbook-backup-borg.md) for setup documentation
| [Buscarron](https://github.com/etkecc/buscarron) | ❌ | Web forms (HTTP POST) to Matrix | [Link](docs/configuring-playbook-bot-buscarron.md) |
- (optional) the [Buscarron](https://gitlab.com/etke.cc/buscarron) bot - see [docs/configuring-playbook-bot-buscarron.md](docs/configuring-playbook-bot-buscarron.md) for setup documentation
### Administration
Basically, this playbook aims to get you up-and-running with all the necessities around Matrix, without you having to do anything else.
Services that help you in administrating and monitoring your Matrix installation.
**Note**: the list above is exhaustive. It includes optional or even some advanced components that you will most likely not need.
| Name | Default? | Description | Documentation |
Sticking with the defaults (which install a subset of the above components) is the best choice, especially for a new installation.
| ---- | -------- | ----------- | ------------- |
You can always re-run the playbook later to add or remove components.
| [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) | ❌ | Web UI tool for administrating users and rooms on your Matrix server | [Link](docs/configuring-playbook-synapse-admin.md) |
## Installation
| 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) |
## Changes
### Misc
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_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) | ❌ | Open source collaborative text editor | [Link](docs/configuring-playbook-etherpad.md) |
See the [i18n/README.md](i18n/README.md) file for more information about translation.
- [etke.cc](https://etke.cc) - matrix-docker-ansible-deploy and system stuff "as a service". That service will create your matrix homeserver on your domain and server (doesn't matter if it's cloud provider or on an old laptop in the corner of your room), (optional) maintains it (server's system updates, cleanup, security adjustments, tuning, etc.; matrix homeserver updates & maintenance) and (optional) provide full-featured email service for your domain
Translations are still work in progress.
## 🤝 Related
You may also be interested in [mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) - another Ansible playbook for self-hosting non-Matrix services (see its [List of supported services](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/supported-services.md)).
mash-playbook also makes use of [Traefik](./docs/configuring-playbook-traefik.md) as its reverse-proxy, so with minor [interoperability adjustments](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/interoperability.md), you can make matrix-docker-ansible-deploy and mash-playbook co-exist and host Matrix and non-Matrix services on the same server.
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 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.
`matrix-nginx-proxy` is no longer in the way of us being interoperable, but its ugly internal details are still there. It is one more proxy in the long chain of reverse-proxies we have and we'd like to cut it out. This would both make things simpler and also boost performance.
The delay in eliminating `matrix-nginx-proxy` has probably been welcome by many existing users who decided to postpone the Traefik migration a bit longer. In 2024, work on eliminating `matrix-nginx-proxy` will continue with rapid pace. People who are still using `matrix-nginx-proxy` as their front-most reverse-proxy will need to rework their setup. About a year of putting it off has been long enough.
This large Traefik reverse-proxy change was also accompanied by another internal change which began in 2022, but continued in 2023 - **moving non-Matrix-related roles from being internal to the playbook to living their own life outside of it**. Various roles were made more decoupled and moved outside of the playbook, so that other projects (like the [mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) Ansible playbook or other Ansible playbooks) could benefit from them. This led to the **death of a few sibling playbooks** ([gitea-docker-ansible-deploy](https://github.com/spantaleev/gitea-docker-ansible-deploy), [nextcloud-docker-ansible-deploy](https://github.com/spantaleev/nextcloud-docker-ansible-deploy), [peertube-docker-ansible-deploy](https://github.com/spantaleev/peertube-docker-ansible-deploy), [vaultwarden-docker-ansible-deploy](https://github.com/spantaleev/vaultwarden-docker-ansible-deploy)), but brought life to something better, which supports all these services and more.
[mash-playbook](https://github.com/mother-of-all-self-hosting/mash-playbook) is a new Ansible playbook that a few of us (matrix-docker-ansible-deploy contributors) have launched in 2023. It has quickly grown to supports [60+ services](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/supported-services.md) and aims to do the same for [FOSS](https://en.wikipedia.org/wiki/Free_and_open-source_software) service hosting, as matrix-docker-ansible-deploy has done for Matrix - providing a clean and secure way to run a bunch of services in containers on a regular server (that is to say, without Kubernetes, etc.). Thanks to Traefik and Ansible role reuse, it's easy to host both mash-playbook services and matrix-docker-ansible-deploy services on the same server - see mash-playbook's [interoperability](https://github.com/mother-of-all-self-hosting/mash-playbook/blob/main/docs/interoperability.md) documentation page. If you've been looking for a holiday project or your New Year's Resolutions list contains "self-hosting more services", then you're welcome to give this new playbook a try and join its Matrix room ([#mash-playbook:devture.com](https://matrix.to/#/#mash-playbook:devture.com)).
Because many of the roles are now external to this playbook (defined in the [requirements.yml](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/da27655ef34999fa924bc0a5e641dbd9ba06f133/requirements.yml) file), running `make roles` (or better yet `just roles` via the [just tool](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#support-for-running-commands-via-just)) becomes a necessity each time one pulls playbook updates (`git pull`). Pulling external roles happens via the [ansible-galaxy](https://docs.ansible.com/ansible/latest/cli/ansible-galaxy.html) command-line tool, but if available, the playbook would also use the much faster [agru](https://github.com/etkecc/agru) tool (developed by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) this year).
With the internal (but important) details out of the way, we can now talk more about **new features that landed in matrix-docker-ansible-deploy in 2023**.
The following **new****bridges** were added to the playbook in 2023:
* (2023-01-11) [mautrix-slack](https://mau.dev/mautrix/slack), thanks to a PR by [Cody Neiman](https://github.com/xangelix) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#mautrix-slack-support))
* (2023-07-21) [mautrix-gmessages](https://github.com/mautrix/gmessages), thanks to a PR by [Shreyas Ajjarapu](https://github.com/shreyasajj) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#mautrix-gmessages-support))
* (2023-08-23) [mautrix-wsproxy](https://github.com/mautrix/wsproxy) for Apple iMessage bridging (when combined with the [mautrix-imessage](https://github.com/mautrix/imessage) bridge running on your Mac or Android phone), thanks to a PR by [Johan Swetzén](https://github.com/jswetzen)
This brings the total number of **[bridges that the playbook supports](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/docs/configuring-playbook.md#bridging-other-networks) up to 30**. There are alternative bridge implementations for various networks and protocols, so the number of "unique bridged networks" is surely much smaller.
A few other **major components and changes** landed in 2023:
* (2023-02-10) The [Draupnir](https://github.com/the-draupnir-project/Draupnir) moderation tool (successor to [Mjolnir](https://github.com/matrix-org/mjolnir)), thanks to a PR by [FSG-Cat](https://github.com/FSG-Cat) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#draupnir-moderation-tool-bot-support))
* (2023-02-10) [Matrix User Verification Service](https://github.com/matrix-org/matrix-user-verification-service) to add Matrix Authentication Support to our Jitsi setup, thanks to a PR by [Jakob S.](https://github.com/jakicoll) from [zakk gGmbH](https://github.com/zakk-it) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#matrix-authentication-support-for-jitsi))
* (2023-02-25) The [rageshake](https://github.com/matrix-org/rageshake) bug report server, thanks to a PR by [Benjamin Kampmann](https://github.com/gnunicorn) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#rageshake-support))
* (2023-03-07) [Sliding Sync proxy](https://github.com/matrix-org/sliding-sync) (currently a necessary component for [Element X](https://element.io/labs/element-x) to work), thanks to: [Benjamin Kampmann](https://github.com/gnunicorn) and [FSG-Cat](https://github.com/FSG-Cat) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#sliding-sync-proxy-element-x-support))
* (2023-03-12) synapse-auto-compressor to periodically and automatically run [rust-synapse-compress-state](https://github.com/matrix-org/rust-synapse-compress-state), thanks to a PR by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#synapse-auto-compressor-support))
* (2023-07-17) [matrix-media-repo](https://github.com/turt2live/matrix-media-repo), thanks to a PR by [Michael Hollister](https://github.com/Michael-Hollister) from [FUTO](https://www.futo.org/), the creators of the [Circles app](https://circu.li/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#matrix-media-repo-support))
* (2023-08-31) [SchildiChat Web](https://github.com/SchildiChat/schildichat-desktop) client app (fork of [Element Web)](https://github.com/element-hq/element-web), thanks to a PR by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#schildichat-support))
* (2023-10-18) Postgres parameters auto-tuning, thanks to a PR by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/) (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#postgres-parameters-are-automatically-tuned-now))
* (2023-10-23) Enabling federation of the room directory for Synapse (see the [changelog entry](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md#enabling-allow_public_rooms_over_federation-by-default-for-synapse))
The most recent change in the list above (Enabling federation of the room directory for Synapse) has been somewhat **controversial** as it goes against upstream defaults for Synapse. Nevertheless, we believe it **promotes the well-being of the Matrix Federation by improving room discovery**.
**Matrix Federation Stats** (containing the percentage of servers publishing their room directory publicly) are posted to [TWIM](https://matrix.org/category/this-week-in-matrix/) each week by [Aine](https://gitlab.com/etke.cc) from [etke.cc](https://etke.cc/). The number of servers which [currently published their room directory publicly](https://matrix.org/blog/2023/12/2/this-week-in-matrix-2023-12-22/#matrix-federation-stats) stands at `26.6%`, which is:
- **2.4% more** than when it was when [first published to TWIM](https://matrix.org/blog/2023/11/03/this-week-in-matrix-2023-11-03/#matrix-federation-stats) (1 month earlier, in November)
- likely about **15+% more** than from before we flipped the switch (in October)
Hopefully, Synapse defaults would also change the same way and we'd see the number of servers publicly listing their room directory grow faster.
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.
[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.
Besides these highlights, there were many other relatively large changes announced in our [CHANGELOG](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/850078b7e37401ce91a0f9b686f60b945f6c3a96/CHANGELOG.md) and hundreds of other more minor (but still important) playbook changes that didn't get a mention.
We have **hundreds of contributors to thank for their hard work** on making Matrix self-hosting better for all of us! It should be noted that **support comes in many shapes**, not only in raw code commits and financial help (via [donations](https://liberapay.com/s.pantaleev) or using the [etke.cc managed Matrix hosting service](https://etke.cc/) which is based on matrix-docker-ansible-deploy). It also comes in the shape of code reviews, helping others with [issues](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues), reporting new issues, participating in our support room on Matrix ([#matrix-docker-ansible-deploy:devture.com](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com)), etc. To everyone who has been there to make matrix-docker-ansible-deploy better in 2023, thank you! 🙇♂️
# 2022
For [matrix-docker-ansible-deploy](https://github.com/spantaleev/matrix-docker-ansible-deploy/), 2022 started with **breaking the** [**Synapse**](https://github.com/element-hq/synapse) **monopoly** by [adding support](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#dendrite-support) for the [Dendrite](https://github.com/matrix-org/dendrite) Matrix homeserver in early January. This required various internal changes so that the [Ansible](https://www.ansible.com/) playbook would not be Synapse-centric anymore. This groundwork paved the way for continuing in this direction and we [added support](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#conduit-support) for [Conduit](https://conduit.rs/) in August.
When it comes to the `matrix-docker-ansible-deploy` Ansible playbook, 2022 was the year of the non-Synapse homeserver implementation. In practice, none of these homeserver implementations seem ready for prime-time yet and there is no migration path when coming from Synapse. Having done our job of adding support for these alternative homeserver implementations, we can say that we're not getting in the way of future progress. It's time for the Dendrite developers to push harder (development-wise) and for the Synapse developers to take a well-deserved long (infinite) break, and we may get to see more people migrating away from Synapse in the next year(s).
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
* [Cinny](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#cinny-support) client support
* [synapse-s3-storage-provider](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#synapse-s3-storage-provider-support) to stop the Synapse media store from being a scalability problem. This brought along [another feature](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#synapse-container-image-customization-support) - an easier way to customize the Synapse container image without having to fork and self-build all of it from scratch
Besides these major user-visible changes, a lot of work also happened **under the hood**:
* we made [major improvements to Synapse workers](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#potential-backward-compatibility-break-major-improvements-to-synapse-workers) - adding support for stream writers and for running multiple workers of various kinds (federation senders, pushers, background task processing workers, etc.)
* we [improved the compatibility of (Synapse + workers) with the rest of the playbook](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#backward-compatibility-break-changing-how-reverse-proxying-to-synapse-works---now-via-a-matrix-synapse-reverse-proxy-companion-service) by introducing a new `matrix-synapse-reverse-proxy-companion-service` service
* we started [splitting various Ansible roles out of the Matrix playbook and into independent roles](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#the-playbook-now-uses-external-roles-for-some-things) (e.g. `matrix-postgres` -> [ansible-role-postgres](https://github.com/mother-of-all-self-hosting/ansible-role-postgres)), which could be included in other Ansible playbooks. In fact, these roles already power a few **interesting other sibling playbooks**:
* [gitea-docker-ansible-deploy](https://github.com/spantaleev/gitea-docker-ansible-deploy), for deploying a [Gitea](https://gitea.io/) (self-hosted [Git](https://git-scm.com/) service) server
* [nextcloud-docker-ansible-deploy](https://github.com/spantaleev/nextcloud-docker-ansible-deploy), for deploying a [Nextcloud](https://nextcloud.com/) groupware server
* [vaultwarden-docker-ansible-deploy](https://github.com/spantaleev/vaultwarden-docker-ansible-deploy), for deploying a [Vaultwarden](https://github.com/dani-garcia/vaultwarden) password manager server (unofficial [Bitwarden](https://bitwarden.com/) compatible server)
These sibling playbooks co-exist nicely with one another due to using [Traefik](https://traefik.io/) for reverse-proxying, instead of trying to overtake the whole server by running their own [nginx](https://nginx.org/) reverse-proxy. Hopefully soon, the Matrix playbook will follow suit and be powered by Traefik by default.
Last, but not least, to optimize our [etke.cc managed Matrix hosting service](https://etke.cc/)'s performance (but also individual Ansible playbook runs for people self-hosting by themselves using the playbook), we've [improved playbook runtime 2-5x](https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/ba09705f7fbaf0108652ecbe209793b1d935eba7/CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) by employing various Ansible tricks.
find "$instagram_role_path" -type f |whileread -r file;do
sed --in-place 's/matrix_mautrix_meta_messenger_/matrix_mautrix_meta_instagram_/g'"$file"
sed --in-place 's/mautrix-meta-messenger/mautrix-meta-instagram/g'"$file"
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
# Create the README.md file with the license header
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
echo"" >> $instagram_role_path/README.md
echo"If you'd like to make a change to this role, consider making it to the \`matrix-mautrix-meta-messenger\` role instead." >> $instagram_role_path/README.md
- [FAQ](faq.md) - lots of questions and answers. Jump to [Prerequisites](prerequisites.md) to avoid reading too much and to just start a guided installation.
## ⬇️ Installation guides <!-- NOTE: the 🚀 emoji is used by "Getting started" on README.md -->
- [Prerequisites](prerequisites.md) - go here to a guided installation using this Ansible playbook
There are two installation guides available for beginners and advanced users.
-[Configuring your DNS server](configuring-dns.md)
-⚡ **[Quick start](quick-start.md) (for beginners)**: this is recommended for those who do not have an existing Matrix server and want to start quickly with "opinionated defaults".
-[Getting this playbook's source code](getting-the-playbook.md)
-**Full installation guide (for advanced users)**: if you need to import an existing Matrix server's data into the new server or want to learn more while setting up the server, follow this guide.
- [Configuring the playbook](configuring-playbook.md)
- [Prerequisites](prerequisites.md)
- [Installing](installing.md)
- [Configuring DNS settings](configuring-dns.md)
- **Importing data from another server installation**
- [Getting the playbook](getting-the-playbook.md)
- [Importing an existing SQLite database (from another Synapse installation)](importing-synapse-sqlite.md) (optional)
- [Configuring the playbook](configuring-playbook.md)
- [Importing an existing Postgres database (from another installation)](importing-postgres.md) (optional)
- [Installing](installing.md)
- [Importing `media_store` data files from an existing Synapse installation](importing-synapse-media-store.md) (optional)
## 🛠️ Configuration options
- [Registering users](registering-users.md)
<!--
NOTE:
-Avoid putting the same anchor links as configuring-playbook.md lists under the "configuration options" section. Note that most of them are linked to "configure-playbook-*.md" and their titles start with "Setting up" (e.g. "Setting up Hydrogen").
You can check useful documentation for configuring components here: [Configuring the playbook](configuring-playbook.md)
- [Configuring service discovery via .well-known](configuring-well-known.md)
- [Administration](configuring-playbook.md#administration) — services that help you in administrating and monitoring your Matrix installation
- [Maintenance / checking if services work](maintenance-checking-services.md)
- [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
- [Maintenance / Synapse](maintenance-synapse.md)
- [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
- [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
<!-- NOTE: sort list items above alphabetically -->
- [Other specialized services](configuring-playbook.md#other-specialized-services) — various services that don't fit any other categories
## 👨🔧 Maintenance
If your server and services experience issues, feel free to come to [our support room](https://matrix.to/#/#matrix-docker-ansible-deploy:devture.com) and ask for help.
<!-- NOTE: sort list items alphabetically -->
- [Maintenance and Troubleshooting](maintenance-and-troubleshooting.md)
- [Maintenance and Troubleshooting](maintenance-and-troubleshooting.md)
As stated in the [Prerequisites](prerequisites.md), currently only `x86_64` is fully supported. However, it is possible to set the target architecture, and some tools can be built on the host or other measures can be used.
As stated in the [Prerequisites](prerequisites.md), currently only `amd64` (`x86_64`) is fully supported.
To that end add the following variable to your `vars.yml` file (see [Configuring playbook](configuring-playbook.md)):
The playbook automatically determines the target server's architecture (the `matrix_architecture` variable) to be one of the following:
Currently supported architectures are the following:
-`amd64` (the default)
-`arm64`
-`arm32`
-`arm32`
-`arm64`
so for the Raspberry Pi, the following should be in your `vars.yml` file:
Some tools and container images can be built on the host or other measures can be used to install on that architecture.
```yaml
matrix_architecture:"arm32"
```
## Implementation details
## Implementation details
For `amd64`, prebuilt container images (see the [container images we use](container-images.md)) are used for all components (except [Hydrogen](configuring-playbook-client-hydrogen.md), which goes through self-building).
For `amd64`, prebuilt container images (see the [container images we use](container-images.md)) are used for all components (except [Hydrogen](configuring-playbook-client-hydrogen.md), which goes through self-building).
For other architectures, components which have a prebuilt image make use of it. If the component is not available for the specific architecture, [self-building](self-building.md) will be used. Not all components support self-building though, so your mileage may vary.
For other architecture (`arm64`, `arm32`), components which have a prebuilt image make use of it. If the component is not available for the specific architecture, [self-building](self-building.md) will be used. Not all components support self-building though, so your mileage may vary.
This playbook is meant to be run using [Ansible](https://www.ansible.com/).
This playbook is meant to be run using [Ansible](https://www.ansible.com/).
Ansible typically runs on your local computer and carries out tasks on a remote server.
Ansible typically runs on your local computer and carries out tasks on a remote server. If your local computer cannot run Ansible, you can also run Ansible on some server somewhere (including the server you wish to install to).
If your local computer cannot run Ansible, you can also run Ansible on some server somewhere (including the server you wish to install to).
## Supported Ansible versions
## Supported Ansible versions
Ansible 2.7.1 or newer is required ([last discussion about Ansible versions](https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/743)).
Note: Ubuntu 20.04 ships with Ansible 2.9.6 which is a buggy version (see this [bug](https://bugs.launchpad.net/ubuntu/+source/ansible/+bug/1880359)), which can't be used in combination with a host running new systemd (more details in [#517](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/517), [#669](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/669)). If this problem affects you, you can: avoid running Ubuntu 20.04 on your host; run Ansible from another machine targeting your host; or try to upgrade to a newer Ansible version (see below).
## Checking your Ansible version
In most cases, you won't need to worry about the Ansible version.
The playbook will try to detect it and tell you if you're on an unsupported version.
To manually check which version of Ansible you're on, run: `ansible --version`.
To manually check which version of Ansible you're on, run: `ansible --version`.
If you're on an old version of Ansible, you should [upgrade Ansible to a newer version](#upgrading-ansible) or [use Ansible via Docker](#using-ansible-via-docker).
For the **best experience**, we recommend getting the **latest version of Ansible available**.
We're not sure what's the minimum version of Ansible that can run this playbook successfully. The lowest version that we've confirmed (on 2022-11-26) to be working fine is: `ansible-core` (`2.11.7`) combined with `ansible` (`4.10.0`).
If your distro ships with an Ansible version older than this, you may run into issues. Consider [Upgrading Ansible](#upgrading-ansible) or [using Ansible via Docker](#using-ansible-via-docker).
## Upgrading Ansible
## Upgrading Ansible
@ -30,44 +30,97 @@ Depending on your distribution, you may be able to upgrade Ansible in a few diff
- by using an additional repository (PPA, etc.), which provides newer Ansible versions. See instructions for [CentOS](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-rhel-centos-or-fedora), [Debian](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-debian), or [Ubuntu](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-ubuntu) on the Ansible website.
- by using an additional repository (PPA, etc.), which provides newer Ansible versions. See instructions for [CentOS](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-rhel-centos-or-fedora), [Debian](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-debian), or [Ubuntu](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#installing-ansible-on-ubuntu) on the Ansible website.
- by removing the Ansible package (`yum remove ansible` or `apt-get remove ansible`) and installing via [pip](https://pip.pypa.io/en/stable/installing/) (`pip install ansible`).
- by removing the Ansible package (`yum remove ansible` or `apt-get remove ansible`) and installing via [pip](https://pip.pypa.io/en/stable/installation/) (`pip install ansible`).
If using the `pip` method, do note that the `ansible-playbook` binary may not be on the `$PATH` (https://linuxconfig.org/linux-path-environment-variable), but in some more special location like `/usr/local/bin/ansible-playbook`. You may need to invoke it using the full path.
If using the `pip` method, do note that the `ansible-playbook` binary may not be on the `$PATH` (https://linuxconfig.org/linux-path-environment-variable), but in some more special location like `/usr/local/bin/ansible-playbook`. You may need to invoke it using the full path.
**Note**: Both of the above methods are a bad way to run system software such as Ansible. If you find yourself needing to resort to such hacks, please consider reporting a bug to your distribution and/or switching to a sane distribution, which provides up-to-date software.
**Note**: Both of the above methods are a bad way to run system software such as Ansible.
If you find yourself needing to resort to such hacks, please consider reporting a bug to your distribution and/or switching to a sane distribution, which provides up-to-date software.
## Using Ansible via Docker
## Using Ansible via Docker
Alternatively, you can run Ansible on your computer from 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).
Here's a sample command to get you started (run this from the playbook's directory):
This ensures that:
```bash
- you're using a very recent Ansible version, which is less likely to be incompatible with the playbook
docker run -it --rm \
- 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).
### Running Ansible in a container on the Matrix server itself
To run Ansible in a (Docker) container on the Matrix server itself, you need to have a working Docker installation. Docker is normally installed by the playbook, so this may be a bit of a chicken and egg problem. To solve it:
- 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).
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: `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 \
--privileged \
--pid=host \
-w /work \
-w /work \
-v `pwd`:/work \
--mount type=bind,src=`pwd`,dst=/work \
-v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa:ro \
--entrypoint=/bin/sh \
--entrypoint=/bin/sh \
docker.io/devture/ansible:2.11.6-r1
ghcr.io/devture/ansible:11.1.0-r0-0
```
```
The above command tries to mount an SSH key (`$HOME/.ssh/id_rsa`) into the container (at `/root/.ssh/id_rsa`).
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.
If your SSH key is at a different path (not in `$HOME/.ssh/id_rsa`), 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.
You can execute `ansible-playbook` commands as per normal now.
Finally, you can execute `just` or `ansible-playbook …` (e.g. `ansible-playbook --connection=community.docker.nsenter …`) commands as per normal now.
### If you don't use SSH keys for authentication
### Running Ansible in a container on another computer (not the Matrix server)
If you don't use SSH keys for authentication, simply remove that whole line (`-v $HOME/.ssh/id_rsa:/root/.ssh/id_rsa:ro`).
Run this from the playbook's directory:
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:
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 `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 (`--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:
```sh
apk add sshpass
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 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)
> To add an exception for this directory, call:
> git config --global --add safe.directory /work
These errors can be resolved by making `git` trust the playbook directory by running `git config --global --add safe.directory /work`
(Adapted from the [upstream project](https://github.com/element-hq/synapse/blob/develop/docs/CAPTCHA_SETUP.md))
# Overview
# Overview
Captcha can be enabled for this home server. This file explains how to do that.
The captcha mechanism used is Google's [ReCaptcha](https://www.google.com/recaptcha/). This requires API keys from Google.
## Getting keys
Captcha can be enabled for this home server. This file explains how to do that.
The captcha mechanism used is Google's [ReCaptcha](https://www.google.com/recaptcha/). This requires API keys from Google. If your homeserver is Dendrite then [hCapcha](https://www.hcaptcha.com) can be used instead.
## ReCaptcha
### Getting keys
Requires a site/secret key pair from:
Requires a site/secret key pair from:
@ -12,12 +25,39 @@ Requires a site/secret key pair from:
Must be a reCAPTCHA **v2** key using the "I'm not a robot" Checkbox option
Must be a reCAPTCHA **v2** key using the "I'm not a robot" Checkbox option
## Setting ReCaptcha Keys
### Setting ReCaptcha keys
Once registered as above, set the following values:
Once registered as above, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
<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.
To set up Matrix on your domain, you'd need to do some DNS configuration.
To use an identifier like `@<username>:<your-domain>`, you don't actually need
to install anything on the actual `<your-domain>` server.
You do, however need to instruct the Matrix network that Matrix services for `<your-domain>` are delegated
over to `matrix.<your-domain>`.
As we discuss in [Server Delegation](howto-server-delegation.md), there are 2 different ways to set up such delegation:
- either by serving a `https://<your-domain>/.well-known/matrix/server` file (from the base domain!)
- or by using a `_matrix._tcp` DNS SRV record (don't confuse this with the `_matrix-identity._tcp` SRV record described below)
This playbook mostly discusses the well-known file method, because it's easier to manage with regard to certificates.
If you decide to go with the alternative method ([Server Delegation via a DNS SRV record (advanced)](howto-server-delegation.md#server-delegation-via-a-dns-srv-record-advanced)), please be aware that the general flow that this playbook guides you through may not match what you need to do.
## DNS settings for services enabled by default
## 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 |
| 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.
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.
**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 settings for optional services/features
## DNS setting for server delegation (optional)
| Type | Host | Priority | Weight | Port | Target |
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`.
To use such an ID, you don't need to install anything on the actual `example.com` server. Instead, you need to instruct the Matrix network that Matrix services for `example.com` are redirected over to `matrix.example.com`. This redirection is also known as "delegation".
As the table above illustrates, you need to create 2 subdomains (`matrix.<your-domain>` and `element.<your-domain>`) and point both of them to your new server's IP address (DNS `A` record or `CNAME` record is fine).
As we discuss in [Server Delegation](howto-server-delegation.md), server delegation can be configured in either of these ways:
The `element.<your-domain>` subdomain may be necessary, because this playbook installs the [Element](https://github.com/vector-im/element-web) web client for you.
- Setting up a `/.well-known/matrix/server` file on the base domain (`example.com`)
If you'd rather instruct the playbook not to install Element (`matrix_client_element_enabled: false` when [Configuring the playbook](configuring-playbook.md) later), feel free to skip the `element.<your-domain>` DNS record.
- Setting up a `_matrix._tcp` DNS SRV record
The `dimension.<your-domain>` subdomain may be necessary, because this playbook could install the [Dimension integrations manager](http://dimension.t2bot.io/) for you. Dimension installation is disabled by default, because it's only possible to install it after the other Matrixservices are working (see [Setting up Dimension](configuring-playbook-dimension.md) later). If you do not wish to set up Dimension, feel free to skip the `dimension.<your-domain>` DNS record.
For simplicity reasons, this playbook recommends you to set up server delegation via a `/.well-known/matrix/server` file, instead of using a DNS SRV record.
The `jitsi.<your-domain>` subdomain may be necessary, because this playbook could install the [Jitsi video-conferencing platform](https://jitsi.org/) for you. Jitsi installation is disabled by default, because it may be heavy and is not a core required component. To learn how to install it, see our [Jitsi](configuring-playbook-jitsi.md) guide. If you do not wish to set up Jitsi, feel free to skip the `jitsi.<your-domain>` DNS record.
If you choose the recommended method (file-based delegation), you do not need to configure the DNS record to enable server delegation. You will need to add a necessary configuration later, when you [finalize the installation](installing.md#finalize-the-installation) after installing and starting Matrix services.
The `stats.<your-domain>` subdomain may be necessary, because this playbook could install [Grafana](https://grafana.com/) and setup performance metrics for you. Grafana installation is disabled by default, it is not a core required component. To learn how to install it, see our [metrics and graphs guide](configuring-playbook-prometheus-grafana.md). If you do not wish to set up Grafana, feel free to skip the `stats.<your-domain>` DNS record. It is possible to install Prometheus without installing Grafana, this would also not require the `stats.<your-domain>` subdomain.
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)
The `goneb.<your-domain>` subdomain may be necessary, because this playbook could install the [Go-NEB](https://github.com/matrix-org/go-neb) bot. The installation of Go-NEB is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Go-NEB guide](configuring-playbook-bot-go-neb.md). If you do not wish to set up Go-NEB, feel free to skip the `goneb.<your-domain>` DNS record.
---------------------------------------------
The `sygnal.<your-domain>` subdomain may be necessary, because this playbook could install the [Sygnal](https://github.com/matrix-org/sygnal) push gateway. The installation of Sygnal is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Sygnal guide](configuring-playbook-sygnal.md). If you do not wish to set up Sygnal (you probably don't, unless you're also developing/building your own Matrix apps), feel free to skip the `sygnal.<your-domain>` DNS record.
[▶️](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).
The `hydrogen.<your-domain>` subdomain may be necessary, because this playbook could install the [Hydrogen](https://github.com/vector-im/hydrogen-web) web client. The installation of Hydrogen is disabled by default, it is not a core required component. To learn how to install it, see our [configuring Hydrogen guide](configuring-playbook-client-hydrogen.md). If you do not wish to set up Hydrogen, feel free to skip the `hydrogen.<your-domain>` DNS record.
The `cinny.<your-domain>` subdomain may be necessary, because this playbook could install the [Cinny](https://github.com/ajbura/cinny) web client. The installation of cinny is disabled by default, it is not a core required component. To learn how to install it, see our [configuring cinny guide](configuring-playbook-client-cinny.md). If you do not wish to set up cinny, feel free to skip the `cinny.<your-domain>` DNS record.
The `buscarron.<your-domain>` subdomain may be necessary, because this playbook could install the [buscarron](https://github.com/etke.cc/buscarron) bot. The installation of buscarron is disabled by default, it is not a core required component. To learn how to install it, see our [configuring buscarron guide](configuring-playbook-bot-buscarron.md). If you do not wish to set up buscarron, feel free to skip the `buscarron.<your-domain>` DNS record.
## `_matrix-identity._tcp` SRV record setup
To make the [ma1sd](https://github.com/ma1uta/ma1sd) Identity Server (which this playbook may optionally install for you) enable its federation features, set up an SRV record that looks like this:
- Name: `_matrix-identity._tcp` (use this text as-is)
- Content: `10 0 443 matrix.<your-domain>` (replace `<your-domain>` with your own)
This is an optional feature for the optionally-installed [ma1sd service](configuring-playbook-ma1sd.md). See [ma1sd's documentation](https://github.com/ma1uta/ma1sd/wiki/mxisd-and-your-privacy#choices-are-never-easy) for information on the privacy implications of setting up this SRV record.
Note: This `_matrix-identity._tcp` SRV record for the identity server is different from the `_matrix._tcp` that can be used for Synapse delegation. See [howto-server-delegation.md](howto-server-delegation.md) for more information about delegation.
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.
See the project's [documentation](https://github.com/metio/matrix-alertmanager-receiver/blob/main/README.md) to learn what it does and why it might be useful to you.
This service is meant to be used with an external [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) instance. It's **not** meant to be integrated with the [Prometheus & Grafana stack](./configuring-playbook-prometheus-grafana.md) installed by this playbook, because the Alertmanager component is not installed by it.
## Prerequisites
### Register the bot account
This service uses a bot (with a username specified in `matrix_alertmanager_receiver_config_matrix_user_id_localpart`) for delivering messages.
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):
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.
### Join to rooms as the bot manually
ℹ️**This bot does not accept room invitations automatically**. To deliver messages to rooms, the bot must be joined to all rooms manually.
For each new room you would like the bot to deliver alerts to, invite the bot to the room.
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).
```yaml
matrix_alertmanager_receiver_enabled:true
# Uncomment and adjust this part if you'd like to use a username different than the default
### 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 `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`.
When setting, replace `example.com` with your own.
### Extending the configuration
There are some additional things you may wish to configure about the component.
Take a look at:
-`roles/custom/matrix-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
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.
## Usage
Configure your Prometheus Alertmanager with configuration like this:
```yaml
receivers:
- name:matrix
webhook_configs:
- send_resolved:true
url:URL_HERE
route:
group_by:
- namespace
group_interval:5m
group_wait:30s
receiver:"matrix"
repeat_interval:12h
routes:
- receiver:matrix
```
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:
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. The service is an implementation of this approach.
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
To enable the Appservice Double Puppet service, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
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`
`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
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.
Appservice mode can be used together with the regular [Draupnir bot](configuring-playbook-bot-draupnir.md) or independently. Details about the differences between the 2 modes are described below.
## Draupnir Appservice mode compared to Draupnir bot mode
The administrative functions for managing the appservice are alpha quality and very limited. However, the experience of using an appservice-provisioned Draupnir is on par with the experience of using Draupnir from bot mode except in the case of avatar customisation as described later on in this document.
Draupnir for all is the way to go if you need more than 1 Draupnir instance, but you don't need access to Synapse Admin features as they are not accessible through Draupnir for All (Even though the commands do show up in help).
Draupnir for all in the playbook is rate-limit-exempt automatically as its appservice configuration file does not specify any rate limits.
Normal Draupnir does come with the benefit of access to Synapse Admin features. You are also able to more easily customise your normal Draupnir than D4A as D4A even on the branch with the Avatar command (To be Upstreamed to Mainline Draupnir) that command is clunky as it requires the use of things like Element Web devtools. In normal Draupnir this is a quick operation where you login to Draupnir with a normal client and set Avatar and Display name normally.
Draupnir for all does not support external tooling like [MRU](https://mru.rory.gay) as it can't access Draupnir's user account.
## Prerequisites
### Create a main management room
The playbook does not create a management room for your Main Draupnir. You **need to create the room manually** before setting up the bot.
Note that the room must be unencrypted.
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.
> [!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
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ALIAS_HERE`.
There are some additional things you may wish to configure about the component.
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:
You can refer to the upstream [documentation](https://github.com/the-draupnir-project/Draupnir) for more configuration documentation.
**Notes**:
- The playbook ships a full copy of the example config that does transfer to provisioned Draupnirs in the production-bots.yaml.j2 file in the template directory of the role.
- Config extension does not affect the appservices config as this config is not extensible in current Draupnir anyway. It instead touches the config passed to the Draupnirs that your Appservice creates. So the example above (`protectAllJoinedRooms: true`) makes all provisioned Draupnirs protect all joined rooms.
## 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
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` 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 !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
To provision a D4A, you need to start a chat with `@draupnir-main:example.com`. The bot will reject this invite and you will shortly get invited to the Draupnir control room for your newly provisioned Draupnir. From here its just a normal Draupnir experience.
Congratulations if you made it all the way here because you now have a fully working Draupnir for all deployment.
The playbook can install and configure [borgbackup](https://www.borgbackup.org/) with [borgmatic](https://torsion.org/borgmatic/) for you.
SPDX-License-Identifier: AGPL-3.0-or-later
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 borg will store the backups. There are hosted, borg compatible solutions available, such as [BorgBase](https://www.borgbase.com).
# Setting up BorgBackup (optional)
The backup will run based on`matrix_backup_borg_schedule` var (systemd timer calendar), default: 4am every day.
The playbook can install and configure [BorgBackup](https://www.borgbackup.org/) (short: Borg) with [borgmatic](https://torsion.org/borgmatic/) for you.
By default, if you're using the integrated Postgres database server (as opposed to [an external Postgres server](configuring-playbook-external-postgres.md)), Borg backups 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 Borg using the `matrix_backup_borg_postgresql_enabled` variable.
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.
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:
## Prerequisites
- 🌐 [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)
* REPO - borg repository name, it will be initialized on backup start, eg: `matrix`
* PASSPHRASE - passphrase used for encrypting backups, you may generate it with `pwgen -s 64 1` or use any password manager
* PRIVATE KEY - the content of the **private** part of the SSH key you created before
To backup without encryption, add `matrix_backup_borg_encryption: 'none'` to your vars. This will also enable the `matrix_backup_borg_unknown_unencrypted_repo_access_is_ok` variable.
`matrix_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 `matrix_backup_borg_location_exclude_patterns` variable.
Check the `roles/matrix-backup-borg/defaults/main.yml` file for the full list of available options.
## Installing
After configuring the playbook, run the [installation](installing.md) command again:
This playbook sets up services on your Matrix server (`matrix.DOMAIN`).
SPDX-License-Identifier: AGPL-3.0-or-later
To have this server officially be responsible for Matrix services for the base domain (`DOMAIN`), you need to set up [Server Delegation](howto-server-delegation.md).
-->
This is normally done by [configuring well-known](configuring-well-known.md) files on the base domain.
People who don't have a separate server to dedicate to the base domain have trouble arranging this.
# Serving the base domain (optional)
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.
As we discuss in [Server Delegation](howto-server-delegation.md), server delegation / redirection can be configured in either of these ways:
- Setting up a `/.well-known/matrix/server` file on the base domain (`example.com`)
- Setting up a `_matrix._tcp` DNS SRV record
For simplicity reasons, this playbook recommends you to set up server delegation via a `/.well-known/matrix/server` file.
However, those who don't have a separate server to dedicate to the base domain have trouble arranging this.
Usually, there are 2 options:
Usually, there are 2 options:
- either get a separate server for the base domain, just for serving the files necessary for [Server Delegation via a well-known file](howto-server-delegation.md#server-delegation-via-a-well-known-file)
- either get a separate server for the base domain, just for serving the files necessary for [Server Delegation via a well-known file](howto-server-delegation.md#server-delegation-via-a-well-known-file)
- or, arrange for the Matrix server to serve the base domain. This either involves you [using your own webserver](configuring-playbook-own-webserver.md) or making the integrated webserver (`matrix-nginx-proxy`) serve the base domain for you.
- or, arrange for the Matrix server to serve the base domain. This either involves you [using your own webserver](configuring-playbook-own-webserver.md) or making the integrated webserver serve the base domain for you.
This documentation page tells you how to do the latter. With some easy changes, we make it possible to serve the base domain from the Matrix server via the integrated webserver (`matrix-nginx-proxy`).
This documentation page tells you how to do the latter. With some easy changes, we make it possible to serve the base domain from the Matrix server via the integrated webserver.
Just **adjust your DNS records**, so that your base domain is pointed to the Matrix server's IP address (using a DNS `A` record) **and then use the following configuration**:
Just [**adjust your DNS records**](configuring-dns.md), so that your base domain is pointed to the Matrix server's IP address (using a DNS `A` record) **and then add the following configuration** to your `inventory/host_vars/matrix.example.com/vars.yml` file:
- obtain an SSL certificate for the base domain, just like it does for all other domains (see [how we handle SSL certificates](configuring-playbook-ssl-certificates.md))
- obtain an SSL certificate for the base domain, just like it does for all other domains (see [how we handle SSL certificates](configuring-playbook-ssl-certificates.md))
- serve the `/.well-known/matrix/*` files which are necessary for [Federation Server Discovery](configuring-well-known.md#introduction-to-client-server-discovery) (also see [Server Delegation](howto-server-delegation.md)) and [Client-Server discovery](configuring-well-known.md#introduction-to-client-server-discovery)
- serve the `/.well-known/matrix/*` files which are necessary for [Federation Server Discovery](configuring-well-known.md#federation-server-discovery) (also see [Server Delegation](howto-server-delegation.md)) and [Client-Server discovery](configuring-well-known.md#client-server-discovery)
- serve a simple homepage at `https://DOMAIN` with content `Hello from DOMAIN` (configurable via the `matrix_nginx_proxy_base_domain_homepage_template` variable). You can also [serve a more complicated static website](#serving-a-static-website-at-the-base-domain).
- serve a simple homepage at `https://example.com` with content `Hello from example.com` (configurable via the `matrix_static_files_file_index_html_template` variable). You can also [serve a more complicated static website](#serving-a-static-website-at-the-base-domain).
## Serving a static website at the base domain
## Serving a static website at the base domain
By default, when "serving the base domain" is enabled, the playbook hosts a simple `index.html` webpage in`/matrix/nginx-proxy/data/matrix-domain`.
By default, when "serving the base domain" is enabled, the playbook hosts a simple `index.html` webpage at`/matrix/static-files/public/index.html`. The content of this page is taken from the `matrix_static_files_file_index_html_template` variable.
The content of this page is taken from the `matrix_nginx_proxy_base_domain_homepage_template` variable.
If you'd like to host your own static website (more than a single `index.html` page) at the base domain, you can disable the creation of this default `index.html` page like this:
If you'd like to host your own static website (more than a single `index.html` page) at the base domain, you can disable the creation of this default `index.html` page like this:
With this configuration, Ansible will no longer mess around with the `/matrix/nginx-proxy/data/matrix-domain/index.html` file.
With this configuration, Ansible will no longer mess around with the `/matrix/static-files/public/index.html` file.
You are then free to upload any static website files to `/matrix/nginx-proxy/data/matrix-domain` and they will get served at the base domain.
You are then free to upload any static website files to `/matrix/static-files/public` and they will get served at the base domain. You can do so manually or by using the [ansible-role-aux](https://github.com/mother-of-all-self-hosting/ansible-role-aux) Ansible role, which is part of this playbook already.
## Serving a more complicated website at the base domain
## Serving a more complicated website at the base domain
If you'd like to serve an even more complicated (dynamic) website from the Matrix server, relying on the playbook to serve the base domain is not the best choice.
If you'd like to serve an even more complicated (dynamic) website from the Matrix server, relying on the playbook to serve the base domain is not the best choice.
Instead, we recommend that you switch to [using your own webserver](configuring-playbook-own-webserver.md) (preferrably nginx). You can then make that webserver host anything you wish, and still easily plug in Matrix services into it.
You have 2 options.
**One way is to host your base domain elsewhere**. This involves:
- you stopping to serve it from the Matrix server: remove `matrix_static_files_container_labels_base_domain_enabled` from your configuration
- [configuring Matrix Delegation via well-known](./configuring-well-known.md)
**Another way is to serve the base domain from another (your own) container on the Matrix server**. This involves:
- telling the playbook to only serve `example.com/.well-known/matrix` files by adjusting your `vars.yml` configuration like this:
- add an extra: `matrix_static_files_container_labels_base_domain_traefik_path_prefix: /.well-known/matrix`
- building and running a new container on the Matrix server:
- it should be connected to the `traefik` network, so that Traefik can reverse-proxy to it
- it should have appropriate [container labels](https://docs.docker.com/config/labels-custom-metadata/), which instruct Traefik to reverse-proxy to it
How you'll be managing building and running this container is up-to-you. You may use of the primitives from [ansible-role-aux](https://github.com/mother-of-all-self-hosting/ansible-role-aux) Ansible role to organize it yourself, or you can set it up in another way.
🤖 [baibot](https://github.com/etkecc/baibot) (pronounced bye-bot) is a [Matrix](https://matrix.org/) bot developed by [etke.cc](https://etke.cc/) 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. 🤖
It supports [OpenAI](https://openai.com/)'s [ChatGPT](https://openai.com/blog/chatgpt/) models, as many well as other [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md).
It's designed as a more private and [✨ featureful](https://github.com/etkecc/baibot/?tab=readme-ov-file#-features) alternative to [matrix-chatgpt-bot](./configuring-playbook-bot-chatgpt.md). See the [baibot](https://github.com/etkecc/baibot) project and its documentation for more information.
## Prerequisites
API access to one or more LLM [☁️ providers](https://github.com/etkecc/baibot/blob/main/docs/providers.md).
## Adjusting the playbook configuration
There are **a lot of configuration options** (some required, some possibly required, some optional), so they're **split into multiple sections below**:
As mentioned above, **this may not be enough**. Continue with the configuration sections below.
### 👮♂️ Administrator configuration
This is an addition to the [base configuration](#base-configuration).
To specify who is considered a bot [👮♂️ Administrator](https://github.com/etkecc/baibot/blob/main/docs/access.md#administrators), you either need to specify `matrix_bot_baibot_config_access_admin_patterns` or `matrix_admin`. The latter is a single variable which affects all bridges and bots.
If `matrix_admin` is already configured in your `vars.yml` configuration, you can skip this section.
**If necessary**, add the following configuration to your `vars.yml` file:
```yaml
# Uncomment to add one or more admins to this bridge:
#
# matrix_bot_baibot_config_access_admin_patterns:
# - "@*:example.com"
# - "@admin:example.net"
#
# … unless you've made yourself an admin of all bots/bridges like this:
By default, **all users on your homeserver are considered allowed users**. If that's OK, you can skip this section.
This is an addition to the [base configuration](#base-configuration).
To specify who is considered a bot [👥 User](https://github.com/etkecc/baibot/blob/main/docs/access.md#user), you may:
- define an **initial** value for `matrix_bot_baibot_config_initial_global_config_user_patterns` Ansible variable, as shown below
- configure the list at runtime via the bot's `!bai access set-users SPACE_SEPARATED_PATTERNS` command
Configuring `matrix_bot_baibot_config_initial_global_config_user_patterns` is optional, but it can be useful to pre-configure the bot with a list of users who should have access to the bot's features.
**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 `vars.yml` file:
```yaml
# Uncomment and adjust the bot users if necessary:
#
# Subsequent changes to `matrix_bot_baibot_config_initial_global_config_user_patterns` do not affect the bot's behavior.
# Once initially configured, the allowed users list is managed via bot commands, not via Ansible.
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.
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).
Besides the presets, the Ansible role also includes support for configuring additional statically-defined agents via the `matrix_bot_baibot_config_agents_static_definitions_custom` Ansible variable.
Agents defined statically and those created dynamically (via chat) are named differently, so **conflict cannot arise**.
Depending on your propensity for [GitOps](https://en.wikipedia.org/wiki/DevOps#GitOps), you may prefer to define agents statically via Ansible, or you may wish to do it dynamically via chat.
Before proceeding, we recommend reading the upstream documentation on [How to choose a provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#how-to-choose-a-provider). In short, it's probably best to go with [OpenAI](#openai).
#### Anthropic
You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [Anthropic provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#anthropic) with the help of the playbook's preset variables.
Here's an example **addition** to your `vars.yml` file:
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.
💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
#### Groq
You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [Groq provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#groq) with the help of the playbook's preset variables.
Here's an example **addition** to your `vars.yml` file:
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`.
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.
💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
#### Mistral
You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [🇫🇷 Mistral provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#mistral) with the help of the playbook's preset variables.
Here's an example **addition** to your `vars.yml` file:
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`.
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.
💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
#### OpenAI
You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [OpenAI provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openai) with the help of the playbook's preset variables.
The OpenAI provider is **only meant to be used with OpenAI's official API** and compatibility with other services (which do not fully adhere to the OpenAI API spec completely) is limited. **If you're targeting an OpenAI-compatible service**, use the [OpenAI Compatible](#openai-compatible) provider instead.
Here's an example **addition** to your `vars.yml` file:
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`.
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.
💡 You may also wish to use this new agent for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
#### OpenAI Compatible
You can statically-define a single [🤖 agent](https://github.com/etkecc/baibot/blob/main/docs/agents.md) instance powered by the [OpenAI Compatible provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md#openai-compatible) with the help of the playbook's preset variables.
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.
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).
#### Configuring additional agents (without a preset)
The Ansible role may be lacking preset variables for some [☁️ provider](https://github.com/etkecc/baibot/blob/main/docs/providers.md), or you may wish to statically-define an agent on the same provider twice (or more) with different configuration.
It's possible to inject your own agent configuration using the `matrix_bot_baibot_config_agents_static_definitions_custom` Ansible variable.
You can also define providers at runtime, by chatting with the bot, so using Ansible is not a requirement.
Below is an an **example** demonstrating **statically-defining agents via Ansible without using presets**:
Because these are [statically](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md#static-configuration)-defined agents, they will be given a `static/` ID prefix and will be named `static/my-openai-gpt-3.5-turbo-agent` and `static/my-ollama-agent`, respectively.
💡 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).
💡 You may also wish to use these new agents for [🤝 Configuring initial default handlers](#-configuring-initial-default-handlers).
### 🤝 Configuring initial default handlers
This section is only useful if you're [🤖 Configuring agents via Ansible](#-configuring-agents-via-ansible), as it lets you put these agents to use as soon as the bot starts (by adjusting the bot's **initial global configuration**).
If you're not configuring agents via Ansible, you can skip this section.
This section is only useful the first time around. **Once initially configured the global configuration cannot be managed Ansible**, but only via bot commands.
- [💬 text-generation](https://github.com/etkecc/baibot/blob/main/docs/features.md#-text-generation): communicating with you via text
- [🦻 speech-to-text](https://github.com/etkecc/baibot/blob/main/docs/features.md#-speech-to-text): turning your voice messages into text
- [🗣️ text-to-speech](https://github.com/etkecc/baibot/blob/main/docs/features.md#-text-to-speech): turning bot or users text messages into voice messages
- [🖌️ image-generation](https://github.com/etkecc/baibot/blob/main/docs/features.md#-image-generation): generating images based on instructions
- ❓ catch-all: special purposes, indicating use as a fallback (when no specific handler is configured)
[Mixing & matching models](https://github.com/etkecc/baibot/blob/main/docs/features.md#mixing--matching-models) is made possible by the bot's ability to have different [🤝 handlers](https://github.com/etkecc/baibot/blob/main/docs/configuration/handlers.md) configured for different purposes.
This configuration can be done as a global fallback, or per-room. Both of these [🛠️ configurations](https://github.com/etkecc/baibot/blob/main/docs/configuration/README.md) are managed at runtime (viat chat), but **the global configuration can have some initial defaults configured via Ansible**.
You can configure the **initial values** for these via Ansible, via the `matrix_bot_baibot_config_initial_global_config_handler_*` variables.
Example **additional**`vars.yml` configuration:
```yaml
# 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 is managed via bot commands, not via Ansible.
**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:
<!-- 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.
- If you change the bot password (`matrix_bot_baibot_config_user_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_baibot_config_user_password` to let the bot know its new password.
## Usage
To use the bot, invite it to any existing Matrix room (`/invite @baibot:example.com` where `example.com` is your base domain, not the `matrix.` domain).
If you're an allowed bot [👥 user](https://github.com/etkecc/baibot/blob/main/docs/access.md#user) (see [👥 Initial users configuration](#-initial-users-configuration)), the bot will accept your invitation and join the room.
After joining, the bot will introduce itself and show information about the [✨ features](https://github.com/etkecc/baibot/blob/main/docs/features.md) that are enabled for it.
If you've [🤖 configured one or more agents via Ansible](#-configuring-agents-via-ansible) and have [🤝 configured initial default handlers](#configuring-initial-default-handlers), the bot will immediately be able to make use of these agents for this new room. Otherwise, you will need to configure agents and/or handlers via chat commands.
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.
## 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-baibot`.
### 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://gitlab.com/etke.cc/buscarron) for you.
The playbook can install and configure [Buscarron](https://github.com/etkecc/buscarron) for you.
It's a bot you can use to setup **your own helpdesk on matrix**
Buscarron is bot that receives HTTP POST submissions of web forms and forwards them to a Matrix room.
It's a bot you can use to send any form (HTTP POST, HTML) to a (encrypted) matrix room
## Registering the bot user
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.
By default, the playbook will set up the bot with a username like this: `@bot.buscarron:DOMAIN`.
## Adjusting DNS records
(to use a different username, adjust the `matrix_bot_buscarron_login` variable).
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`.
You **need to register the bot user manually** before setting up the bot. You can use the playbook to [register a new user](registering-users.md):
- name: contact # (mandatory) Your form name, will be used as endpoint, eg:buscarron.DOMAIN/contact
- name: contact # (mandatory) Your form name, will be used as endpoint, eg:buscarron.example.com/contact
room:"!yourRoomID:DOMAIN"# (mandatory) Room ID where form submission will be posted
room:"!qporfwt:{{ matrix_domain }}"# (mandatory) Room ID where form submission will be posted
redirect:https://DOMAIN# (mandatory) To what page user will be redirected after the form submission
redirect:https://example.com# (mandatory) To what page user will be redirected after the form submission
ratelimit: 1r/m # (optional) rate limit of the form, format: <max requests>r/<interval:s,m>, eg:1r/s or 54r/m
ratelimit: 1r/m # (optional) rate limit of the form, format: <max requests>r/<interval:s,m>, eg:1r/s or 54r/m
hasemail:1# (optional) form has "email" field that should be validated
extensions:[]# (optional) list of form extensions (not used yet)
extensions:[]# (optional) list of form extensions (not used yet)
matrix_bot_buscarron_spam_hosts:[]# (optional) list of emaildomains/hosts that should be rejected automatically
matrix_bot_buscarron_spamlist:[]# (optional) list of emails/domains/hosts (with wildcards support) that should be rejected automatically
matrix_bot_buscarron_spam_emails:[]# (optional) list of email addresses that should be rejected automatically
```
```
You will also need to add a DNS record so that buscarron can be accessed.
### Adjusting the Buscarron URL (optional)
By default buscarron will use https://buscarron.DOMAIN so you will need to create an CNAME record for `buscarron`.
See [Configuring DNS](configuring-dns.md).
If you would like to use a different domain, add the following to your configuration file (changing it to use your preferred domain):
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 `vars.yml` file:
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
## Installing
After configuring the playbook, run the [installation](installing.md) command again:
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 `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
- If you change the bot password (`matrix_bot_buscarron_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_buscarron_password` to let the bot know its new password.
## Usage
## Usage
To use the bot, invite the `@bot.buscarron:DOMAIN` to the room you specified in a config, after that any point your form to the form url, example for the `contact` form:
To use the bot, invite it to the room you specified on your `vars.yml` file (`/invite @bot.buscarron:example.com` where `example.com` is your base domain, not the `matrix.` domain).
After the bot joins the room, anyone can call the web form via HTTP POST method.
You can also refer to the upstream [documentation](https://gitlab.com/etke.cc/buscarron).
**Note**: to fight against spam, Buscarron is **very aggressive when it comes to banning** and will ban you if:
- you hit the homepage (HTTP `GET` request to `/`)
- you submit a form to the wrong URL (`POST` request to `/non-existing-form`)
-`hasemail` is enabled for the form (like in the example above) and you don't submit an `email` field
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.
## 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.
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.
## Prerequisites
### Obtain an OpenAI API key
To use the bot, you'd need to obtain an API key from [https://platform.openai.com/account/api-keys](https://platform.openai.com/account/api-keys).
### Register the bot account
The playbook does not automatically create users for you. You **need to register the bot user manually** before setting up the bot.
Generate a strong password for the bot. You can create one with a command like `pwgen -s 64 1`.
You can use the playbook to [register a new user](registering-users.md):
### Obtain an access token and create encryption keys
The bot requires an access token to be able to connect to your homeserver. Refer to the documentation on [how to obtain an access token](obtaining-access-tokens.md).
> [!WARNING]
> Access tokens are sensitive information. Do not include them in any bug reports, messages, or logs. Do not share the access token with anyone.
To make sure the bot can read encrypted messages, it will need an encryption key, just like any other new user. While obtaining the access token, follow the prompts to setup a backup key. More information can be found in the [Element documentation](https://element.io/help#encryption6).
## Adjusting the playbook configuration
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `API_KEY_HERE` with the API key retrieved [here](#obtain-an-openai-api-key) and `ACCESS_TOKEN_HERE` with the access token created [here](#obtain-an-access-token-and-create-encryption-keys), respectively.
```yaml
matrix_bot_chatgpt_enabled:true
matrix_bot_chatgpt_openai_api_key:'API_KEY_HERE'
# Uncomment and adjust this part if you'd like to use a username different than the default
# 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:
<!-- 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 bot, invite it to the room you specified on your `vars.yml` file (`/invite @bot.chatgpt:example.com` where `example.com` is your base domain, not the `matrix.` domain).
After the bot joins the room, you can send a message to it. When you do so, use the prefix if you configured it or mention the bot.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-bot-chatgpt`.
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://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](configuring-playbook-bot-mjolnir.md), skip to [this section](#migrating-from-mjolnir-only-required-if-migrating).
## Prerequisites
### 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.
> [!WARNING]
> Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
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)).
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 `vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE` with the one of the room which you have created earlier.
```yaml
# Enable Draupnir
matrix_bot_draupnir_enabled:true
# Uncomment and adjust this part if you'd like to use a username different than the default
# matrix_bot_draupnir_login: bot.draupnir
# Generate a strong password for the bot. You can create one with a command like `pwgen -s 64 1`.
# If creating the user on your own and using `matrix_bot_draupnir_config_accessToken` to login you can comment out this line.
matrix_bot_draupnir_password:PASSWORD_FOR_THE_BOT
# Comment out if using `matrix_bot_draupnir_config_experimentalRustCrypto: true` or `matrix_bot_draupnir_config_accessToken` to login.
**Note**: the `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
Then, invite the bot (`@bot.draupnir:example.com`) to its management room which you have created earlier.
### 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:
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).
> [!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.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
```
**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.
### Abuse Reports
Draupnir can receive reports in the management room.
The bot can intercept the report API endpoint of the client-server API, which requires integration with the reverse proxy in front of the homeserver. If you are using Traefik, this playbook can set this up for you:
Certain protections in Draupnir require the [synapse-http-antispam](https://github.com/maunium/synapse-http-antispam) module and a Synapse homeserver plus homeserver admin status to function. This module can be enabled in the playbook via setting `matrix_bot_draupnir_config_web_synapseHTTPAntispam_enabled` to `true` and making sure that Draupnir admin API access is enabled.
```yaml
# Enables the integration between Draupnir and synapse-http-antispam module.
# Enables draupnir to access Synapse admin APIs. This is required for the module functionality to take full effect.
matrix_bot_draupnir_admin_api_enabled:true
```
These protections need to be manually activated and consulting the [enabling protections](#enabling-built-in-protections) guide can be helpful or consulting upstream documentation.
<!--
NOTE: this is unsupported by the playbook due to the admin API being inaccessible from containers currently.
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
There are some additional things you may wish to configure about the bot.
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.
## 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.
- If you change the bot password (`matrix_bot_draupnir_password` in your `vars.yml` file) subsequently, the bot user's credentials on the homeserver won't be updated automatically. If you'd like to change the bot user's password, use a tool like [synapse-admin](configuring-playbook-synapse-admin.md) to change it, and then update `matrix_bot_draupnir_password` to let the bot know its new password.
## Usage
You can refer to the upstream [documentation](https://the-draupnir-project.github.io/draupnir-documentation/) for additional ways to use and configure Draupnir and for a more detailed usage guide.
Below is a **non-exhaustive quick-start guide** for the impatient.
### Making Draupnir join and protect a room
Draupnir can be told to self-join public rooms, but it's better to follow this flow which works well for all kinds of rooms:
1. Invite the bot to the room manually ([inviting Draupnir to rooms](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#inviting-draupnir-to-rooms)). Before joining, the bot *may* ask for confirmation in the Management Room
2. [Give the bot permissions to do its job](#giving-draupnir-permissions-to-do-its-job)
3. Tell it to protect the room (using the [rooms command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#using-the-draupnir-rooms-command)) by sending the following command to the Management Room: `!draupnir rooms add !qporfwt:example.com`
To have Draupnir provide useful room protection, you need do to a bit more work (at least the first time around). You may wish to [Subscribe to a public policy list](#subscribing-to-a-public-policy-list), [Create your own own policy and rules](#creating-your-own-policy-lists-and-rules) and [Enabling built-in protections](#enabling-built-in-protections).
### Giving Draupnir permissions to do its job
For Draupnir to do its job, you need to [give it permissions](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-protected-rooms#giving-draupnir-permissions) in rooms it's protecting. This involves **giving it an Administrator power level**.
**We recommend setting this power level as soon as the bot joins your room** (and before you create new rules), so that it can apply rules as soon as they are available. If the bot is under-privileged, it may fail to apply protections and may not retry for a while (or until your restart it).
### Subscribing to a public policy list
We recommend **subscribing to a public [policy list](https://the-draupnir-project.github.io/draupnir-documentation/concepts/policy-lists)** using the [watch command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-policy-lists#using-draupnirs-watch-command-to-subscribe-to-policy-rooms).
Policy lists are maintained in Matrix rooms. 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`
#### Creating your own policy lists and rules
We also recommend **creating your own policy lists** with the [list create](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-policy-lists#using-draupnirs-list-create-command-to-create-a-policy-room) command.
You can do so by sending the following command to the Management Room: `!draupnir list create my-bans my-bans-bl`. This will create a policy list having a name (shortcode) of `my-bans` and stored in a public `#my-bans-bl:example.com` room on your server. As soon as you run this command, the bot will invite you to the policy list room.
A policy list does nothing by itself, so the next step is **adding some rules to your policy list**. Policies target a so-called `entity` (one of: `user`, `room` or `server`). These entities are mentioned on the [policy lists](https://the-draupnir-project.github.io/draupnir-documentation/concepts/policy-lists) documentation page and in the Matrix Spec [here](https://spec.matrix.org/v1.11/client-server-api/#mban-recommendation).
The simplest and most useful entity to target is `user`. Below are a few examples using the [ban command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#the-ban-command) and targeting users.
To create rules, you run commands in the Management Room (**not** in the policy list room).
- (ban a single user on a given homeserver): `!draupnir ban @charles:example.com my-bans Rude to others`
- (ban all users on a given homeserver by using a [wildcard](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#wildcards)): `!draupnir ban @*:example.org my-bans Spam server - all users are fake`
As a result of running these commands, you may observe:
- Draupnir creating `m.policy.rule.user` state events in the `#my-bans-bl:example.com` room on your server
- applying these rules against all rooms that Draupnir is an Administrator in
You can undo bans with the [unban command](https://the-draupnir-project.github.io/draupnir-documentation/moderator/managing-users#the-unban-command).
### Enabling built-in protections
You can also **turn on various built-in [protections](https://the-draupnir-project.github.io/draupnir-documentation/protections)** like `JoinWaveShortCircuit` ("If X amount of users join in Y time, set the room to invite-only").
To **see which protections are available and which are enabled**, send a `!draupnir protections` command to the Management Room.
To **see the configuration options for a given protection**, 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`).
To **enable a given protection**, send a command like this: `!draupnir enable PROTECTION_NAME` (e.g. `!draupnir enable JoinWaveShortCircuit`).
To **disable a given protection**, send a command like this: `!draupnir disable PROTECTION_NAME` (e.g. `!draupnir disable JoinWaveShortCircuit`).
**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 playbook can install and configure [Go-NEB](https://github.com/matrix-org/go-neb) for you.
Go-NEB is a Matrix bot written in Go. It is the successor to Matrix-NEB, the original Matrix bot written in Python.
Go-NEB is a Matrix bot written in Go. It is the successor to Matrix-NEB, the original Matrix bot written in Python.
See the project's [documentation](https://github.com/matrix-org/go-neb) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/matrix-org/go-neb/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisites
## Registering the bot user
### Register the bot account
The playbook does not automatically create users for you. The bot requires at least 1 access token to be able to connect to your homeserver.
The playbook does not automatically create users for you. You **need to register the bot user manually** before setting up the bot.
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`.
Choose a strong password for the bot. You can generate a good password with a command like this: `pwgen -s 64 1`.
You can use the playbook to [register a new user](registering-users.md):
You can use the playbook to [register a new user](registering-users.md):
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).
If you use curl, you can get an access token like this:
> [!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
curl -X POST --header 'Content-Type: application/json' -d '{
Alternatively, you can use a full-featured client (such as Element) to log in and get the access token from there (note: don't log out from the client as that will invalidate the token), but doing so might lead to decryption problems. That warning comes from [here](https://github.com/matrix-org/go-neb#quick-start).
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
## Adjusting the playbook configuration
Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
To enable the bot, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `ACCESS_TOKEN_FOR_GONEB_HERE` and `ACCESS_TOKEN_FOR_ANOTHER_GONEB_HERE` with the ones created [above](#obtain-an-access-token).
ClientUserID:"@YOUR_USER_ID:{{ matrix_domain }}"# needs to be an authenticated user so Go-NEB can create webhooks. Check the UserID field in the github_realm in matrix_bot_go_neb_sessions.
ClientUserID:"@alice:{{ matrix_domain }}"# needs to be an authenticated user so Go-NEB can create webhooks. Check the UserID field in the github_realm in matrix_bot_go_neb_sessions.
# Each room will get the notification with the alert rendered with the given template
# Each room will get the notification with the alert rendered with the given template
rooms:
rooms:
"!someroomid:domain.tld":
"!qporfwt:example.com":
text_template:"{% raw %}{{range .Alerts -}} [{{ .Status }}] {{index .Labels \"alertname\" }}: {{index .Annotations \"description\"}} {{ end -}}{% endraw %}"
text_template:"{% raw %}{{range .Alerts -}} [{{ .Status }}] {{index .Labels \"alertname\" }}: {{index .Annotations \"description\"}} {{ end -}}{% endraw %}"
html_template:"{% raw %}{{range .Alerts -}} {{ $severity := index .Labels \"severity\" }} {{ if eq .Status \"firing\" }} {{ if eq $severity \"critical\"}} <font color='red'><b>[FIRING - CRITICAL]</b></font> {{ else if eq $severity \"warning\"}} <font color='orange'><b>[FIRING - WARNING]</b></font> {{ else }} <b>[FIRING - {{ $severity }}]</b> {{ end }} {{ else }} <font color='green'><b>[RESOLVED]</b></font> {{ end }} {{ index .Labels \"alertname\"}} : {{ index .Annotations \"description\"}} <a href=\"{{ .GeneratorURL }}\">source</a><br/>{{end -}}{% endraw %}"
html_template:"{% raw %}{{range .Alerts -}} {{ $severity := index .Labels \"severity\" }} {{ if eq .Status \"firing\" }} {{ if eq $severity \"critical\"}} <font color='red'><b>[FIRING - CRITICAL]</b></font> {{ else if eq $severity \"warning\"}} <font color='orange'><b>[FIRING - WARNING]</b></font> {{ else }} <b>[FIRING - {{ $severity }}]</b> {{ end }} {{ else }} <font color='green'><b>[RESOLVED]</b></font> {{ end }} {{ index .Labels \"alertname\"}} : {{ index .Annotations \"description\"}} <a href=\"{{ .GeneratorURL }}\">source</a><br/>{{end -}}{% endraw %}"
msg_type:"m.text"# Must be either `m.text` or `m.notice`
msg_type:"m.text"# Must be either `m.text` or `m.notice`
```
```
### 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 `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.
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
## Installing
Don't forget to add `goneb.<your-domain>` to DNS as described in [Configuring DNS](configuring-dns.md) before running the playbook.
After configuring the playbook and potentially [adjusting your DNS records](#adjusting-dns-records), run the playbook with [playbook tags](playbook-tags.md) as below:
After configuring the playbook, run the [installation](installing.md) command again:
<!-- 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
## Usage
To use the bot, invite it to any existing Matrix room (`/invite @whatever_you_chose:DOMAIN` where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain, make sure you have permission from the room owner if that's not you).
To use the bot, invite it to any existing Matrix room (`/invite @bot.go-neb:example.com` where `example.com` is your base domain, not the `matrix.` domain). Make sure you are granted with the sufficient permission if you are not the room owner.
Basic usage is like this: `!echo hi` or `!imgur puppies` or `!giphy matrix`
Basic usage is like this: `!echo hi` or `!imgur puppies` or `!giphy matrix`
If you enabled the github_cmd service you can get the supported commands via `!github help`
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).
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://gitlab.com/etke.cc/honoroit) for you.
The playbook can install and configure [Honoroit](https://github.com/etkecc/honoroit) for you.
It's a bot you can use to setup **your own helpdesk on matrix**
It's a bot you can use to setup **your own helpdesk on matrix**
See the project's [documentation](https://gitlab.com/etke.cc/honoroit#how-it-looks-like) to learn what it does with screenshots and why it might be useful to you.
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)
## Registering the bot user
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.
By default, the playbook will set up the bot with a username like this: `@honoroit:DOMAIN`.
(to use a different username, adjust the `matrix_bot_honoroit_login` variable).
You **need to register the bot user manually** before setting up the bot. You can use the playbook to [register a new user](registering-users.md):
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 `vars.yml` file:
```yaml
# Change the default hostname and path prefix
matrix_bot_honoroit_hostname:honoroit.example.com
matrix_bot_honoroit_path_prefix:/
```
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`.
When setting, replace `example.com` with your own.
### Extending the 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
## Installing
After configuring the playbook, run the [installation](installing.md) command again:
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 `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
- If you change the bot password (`matrix_bot_honoroit_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_honoroit_password` to let the bot know its new password.
## Usage
## Usage
To use the bot, invite the `@honoroit:DOMAIN` to the room you specified in config, after that any matrix user can send a message to the `@honoroit:DOMAIN` to start a new thread in that room.
To use the bot, invite it to the room you specified on your `vars.yml` file (`/invite @honoroit:example.com` where `example.com` is your base domain, not the `matrix.` domain).
Send `!ho help` to the room to see the bot's help menu for additional commands.
After the bot joins the room, any Matrix user can send a message to it to start a new thread in that room.
You can also refer to the upstream [documentation](https://gitlab.com/etke.cc/honoroit#features).
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:
The playbook can install and configure [matrix-registration-bot](https://github.com/moan0s/matrix-registration-bot) for you.
The playbook can install and configure [matrix-registration-bot](https://github.com/moan0s/matrix-registration-bot) for you.
The bot allows you to easily **create and manage registration tokens**. It can be used for an invitation-based server,
The bot allows you to easily **create and manage registration tokens** aka. invitation codes. It can be used for an invitation-based server, where you invite someone by sending them a registration token (tokens look like this: `rbalQ0zkaDSRQCOp`). They can register as per normal but have to provide a valid registration token in the final step of the registration process.
where you invite someone by sending them a registration token. They can register as normal but have to provide a valid
registration token in a final step of the registration.
See the project's [documentation](https://github.com/moan0s/matrix-registration-bot#supported-commands) to learn what it
See the project's [documentation](https://github.com/moan0s/matrix-registration-bot/blob/master/README.md) to learn what it does and why it might be useful to you.
does and why it might be useful to you.
## Registering the bot user
By default, the playbook will set use the bot with a username like this: `@bot.matrix-registration-bot:DOMAIN`.
(to use a different username, adjust the `matrix_bot_matrix_registration_bot_matrix_user_id_localpart` variable).
You **need to register the bot user manually** before setting up the bot. You can use the playbook to [register a new user](registering-users.md):
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
## Installing
After configuring the playbook, run the [installation](installing.md) command again:
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.
- If you change the bot password (`matrix_bot_matrix_registration_bot_bot_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_matrix_registration_bot_bot_password` to let the bot know its new password.
## Usage
## Usage
To use the bot, create a **non-encrypted** room and invite`@bot.matrix-registration-bot:DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
To use the bot, start a chat with`@bot.matrix-registration-bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
In this room send `help`and the bot will reply with all options.
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).
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:
The playbook can install and configure [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) for you.
The playbook can install and configure [matrix-reminder-bot](https://github.com/anoadragon453/matrix-reminder-bot) for you.
It's a bot you can use to **schedule one-off & recurring reminders and alarms**.
It's a bot you can use to **schedule one-off & recurring reminders and alarms**.
See the project's [documentation](https://github.com/anoadragon453/matrix-reminder-bot#usage) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/anoadragon453/matrix-reminder-bot/blob/master/README.md) to learn what it does and why it might be useful to you.
## Registering the bot user
By default, the playbook will set up the bot with a username like this: `@bot.matrix-reminder-bot:DOMAIN`.
(to use a different username, adjust the `matrix_bot_matrix_reminder_bot_matrix_user_id_localpart` variable).
You **need to register the bot user manually** before setting up the bot. You can use the playbook to [register a new user](registering-users.md):
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
## Installing
After configuring the playbook, run the [installation](installing.md) command again:
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.
- If you change the bot password (`matrix_bot_matrix_reminder_bot_matrix_user_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_matrix_reminder_bot_matrix_user_password` to let the bot know its new password.
## Usage
## Usage
To use the bot, start a chat with `@bot.matrix-reminder-bot:DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
To use the bot, start a chat with `@bot.matrix-reminder-bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
You can also add the bot to any existing Matrix room (`/invite @bot.matrix-reminder-bot:DOMAIN`).
You can also add the bot to any existing Matrix room (`/invite @bot.matrix-reminder-bot:example.com`).
Basic usage is like this: `!remindme in 2 minutes; This is a test`
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.
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).
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.
After setting up maubot, you can use the web management interface to make it do things. The default location of the management interface is `matrix.example.com/_matrix/maubot/`
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:
```yaml
matrix_bot_maubot_enabled:true
# Uncomment and adjust this part if you'd like to use a username different than the default
# matrix_bot_maubot_login: bot.maubot
# Generate a strong password for the bot. You can create one with a command like `pwgen -s 64 1`.
You can add multiple admins. The admin accounts are only used to access the maubot administration interface.
### 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 `vars.yml` file:
```yaml
# Change the default hostname and path prefix
matrix_bot_maubot_hostname:maubot.example.com
matrix_bot_maubot_path_prefix:/
```
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`.
When setting, replace `example.com` with your own.
### Extending the 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
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 `ensure-matrix-users-created` playbook tag makes the playbook automatically create the bot's user account.
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
- If you change the bot password (`matrix_bot_maubot_initial_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_maubot_initial_password` to let the bot know its new password.
## Usage
By default, you can visit `matrix.example.com/_matrix/maubot/` to manage your available plugins, clients and instances.
You should start in the following order
1.**Create one or more clients**: A client is a Matrix account which the bot will use to message. By default, the playbook creates a `bot.maubot` account (as per the configuration above). You only need to [obtain an access token](#obtaining-an-access-token) for it
2.**Upload some Plugins**: Plugins can be obtained from [here](https://github.com/maubot/maubot#plugins) or any other source.
3.**Create an instance**: An instance is the actual bot. You have to specify a client which the bot instance will use and the plugin (how the bot will behave)
## Obtain an access token
This can be done via `mbc login` then `mbc auth` (see the [maubot documentation](https://docs.mau.fi/maubot/usage/cli/auth.html)). To run these commands, you'll first need to `exec` into the maubot container with `docker exec -it matrix-bot-maubot sh`.
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.
## 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:
If you would like Mjolnir to be able to deactivate users, move aliases, shutdown rooms, etc then it must be a server admin so you need to change `admin=no` to `admin=yes` in the command above.
If you would like Mjolnir to be able to deactivate users, move aliases, shutdown rooms, etc then it must be a server admin so you need to change `admin=no` to `admin=yes` in the command above.
### Obtain an access token
## 2. Get 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).
If you use curl, you can get an access token like this:
> [!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
curl -X POST --header 'Content-Type: application/json' -d '{
Alternatively, you can use a full-featured client (such as Element) to log in and get the access token from there (note: don't log out from the client as that will invalidate the token).
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, Mjolnir 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.
## 3. Make sure the account is free from rate limiting
**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).
You will need to prevent Synapse from rate limiting the bot's account. This is not an optional step. If you do not do this step Mjolnir will crash. [Currently there is no Synapse config option for this](https://github.com/matrix-org/synapse/issues/6286) so you have to manually edit the Synapse database. Manually editing the Synapse database is rarely a good idea but in this case it is required. Please ask for help if you are uncomfortable with these steps.
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).
1. Copy the statement below into a text editor.
#### Add the configuration
```
To expose the APIs publicly, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
INSERT INTO ratelimit_override VALUES ('@bot.mjolnir:DOMAIN', 0, 0);
```
1. Change the username (`@bot.mjolnir:DOMAIN`) to the username you used when you registered the bot's account. You must change `DOMAIN` to your server's domain.
1. Get a database terminal by following these steps: [maintenance-postgres.md#getting-a-database-terminal](maintenance-postgres.md#getting-a-database-terminal)
1. Connect to Synapse's database by typing `\connect synapse` into the database terminal
1. Paste in the `INSERT INTO` command that you edited and press enter.
You can run `SELECT * FROM ratelimit_override;` to see if it worked. If the output looks like this:
Using your own account, create a new invite only room that you will use to manage the bot. This is the room where you will see the status of the bot and where you will send commands to the bot, such as the command to ban a user from another room. Anyone in this room can control the bot so it is important that you only invite trusted users to this room. The room must be unencrypted since the playbook does not support installing Pantalaimon yet.
Once you have created the room you need to copy the room ID so you can tell the bot to use that room. In Element you can do this by going to the room's settings, clicking Advanced, and then coping the internal room ID. The room ID will look something like `!QvgVuKq0ha8glOLGMG:DOMAIN`.
Finally invite the `@bot.mjolnir:DOMAIN` account you created earlier into the room.
## 5. Adjusting the playbook configuration
Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
You must replace `ACCESS_TOKEN_FROM_STEP_2_GOES_HERE` and `ROOM_ID_FROM_STEP_4_GOES_HERE` with the your own values.
Add the following configuration to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file (adapt to your needs):
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.
> [!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 ADMIN_ACCESS_TOKEN_HERE" -X POST https://matrix.example.com/_synapse/admin/v1/users/@bot.mjolnir:example.com/override_ratelimit
```
**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.
> [!WARNING]
> Anyone in this room can control the bot so it is important that you only invite trusted users to this room.
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 `vars.yml` file. Make sure to replace `MANAGEMENT_ROOM_ID_HERE` with the one of the room which you have created just now.
Decide whether you want Mjolnir to be capable of operating in end-to-end encrypted (E2EE) rooms. This includes the management room and the moderated rooms.
To support E2EE, Mjolnir needs to [use Pantalaimon](configuring-playbook-pantalaimon.md).
#### Configuration with E2EE support
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 `vars.yml` file (adapt to your needs):
```yaml
# Enable Pantalaimon. See docs/configuring-playbook-pantalaimon.md
matrix_pantalaimon_enabled:true
# Tell Mjolnir to use Pantalaimon
matrix_bot_mjolnir_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 Mjolnir uses to reach the homeserver, one through Pantalaimon and one "raw". This example is taken from the playbook's `group_vars`:
```yaml
# Endpoint URL that Mjolnir uses to interact with the Matrix homeserver (client-server API).
# Set this to the pantalaimon URL if you're using that.
matrix_bot_mjolnir_homeserver_url:"{{ 'http://matrix-pantalaimon:8009' if matrix_bot_mjolnir_pantalaimon_use else matrix_addons_homeserver_client_api_url }}"
# Endpoint URL that Mjolnir 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.
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 `vars.yml` file. Make sure to replace `ACCESS_TOKEN_HERE` with the one created [above](#obtain-an-access-token).
There are some additional things you may wish to configure about the bot.
After configuring the playbook, run the [installation](installing.md) command:
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:
## Usage
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.
You can configure additional options by adding the `matrix_bot_mjolnir_configuration_extension_yaml` variable to your `inventory/host_vars/matrix.DOMAIN/vars.yml` file.
For example to change mjolnir's `recordIgnoredInvites` option to `true` you would add the following to your `vars.yml` file.
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.
- If you change the Pantalaimon's password (`matrix_bot_mjolnir_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_mjolnir_pantalaimon_password` to let Pantalaimon know its new password.
## Usage
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:
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) bridge supported by the playbook.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
The playbook can install and configure [matrix-appservice-discord](https://github.com/Half-Shot/matrix-appservice-discord) for you.
# Setting up Appservice Discord bridging (optional)
See the project's [documentation](https://github.com/Half-Shot/matrix-appservice-discord/blob/master/README.md) to learn what it does and why it might be useful to you.
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) and [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridges supported by the playbook.
- For using as a Bot we are recommend the Appservice Discord bridge (the one being discussed here), because it supports plumbing.
- For personal use we recommend the [mautrix-discord](configuring-playbook-bridge-mautrix-discord.md) bridge, because it is the most fully-featured and stable of the 3 Discord bridges supported by the playbook.
The playbook can install and configure [matrix-appservice-discord](https://github.com/matrix-org/matrix-appservice-discord) for you.
## Setup Instructions
See the project's [documentation](https://github.com/matrix-org/matrix-appservice-discord/blob/master/README.md) to learn what it does and why it might be useful to you.
Instructions loosely based on [this](https://github.com/Half-Shot/matrix-appservice-discord#setting-up).
## Prerequisites
1.Create a Discord Application [here](https://discordapp.com/developers/applications).
Create a Discord Application [here](https://discordapp.com/developers/applications). Then retrieve Client ID, and create a bot from the Bot tab and retrieve the Bot token.
2. Retrieve Client ID.
3. Create a bot from the Bot tab and retrieve the Bot token.
## Adjusting the playbook configuration
4. Enable the bridge with the following configuration in your `vars.yml` file:
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
# As of Synapse 1.90.0, uncomment to enable the backwards compatibility (https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900) that this bridge needs.
# Note: This deprecated method is considered insecure.
#
# matrix_synapse_configuration_extension_yaml: |
# use_appservice_legacy_authorization: true
```
```
5. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
### 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-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`
`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.
Other configuration options are available via the `matrix_appservice_discord_configuration_extension_yaml` variable.
## Self-Service Bridging (Manual)
## Self-Service Bridging (Manual)
Self-service bridging allows you to bridge specific and existing Matrix rooms to specific Discord rooms. This is disabled by default, so it must be enabled by adding this to your `vars.yml`:
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:
_Note: If self-service bridging is not enabled, `!discord help` commands will return no results._
**Note**: If self-service bridging is not enabled, `!discord help` commands will return no results.
Once self-service is enabled:
### Usage
1. Start a chat with `@_discord_bot:<YOUR_DOMAIN>` and say `!discord help bridge`.
Once self-service is enabled, start a chat with `@_discord_bot:example.com` and say `!discord help bridge`.
2. Follow the instructions in the help output message. If the bot is not already in the Discord server, follow the provided invite link. This may require you to be a administrator of the Discord server.
_Note: Encrypted Matrix rooms are not supported as of writing._
Then, follow the instructions in the help output message.
On the Discord side, you can say `!matrix help` to get a list of available commands to manage the bridge and Matrix users.
If the bot is not already in the Discord server, follow the provided invite link. This may require you to be a administrator of the Discord server.
On the Discord side, send `!matrix help` to the bot to see the available commands for managing the bridge and Matrix users.
**Note**: Encrypted Matrix rooms are not supported as of writing.
## Portal Bridging (Automatic)
## Portal Bridging (Automatic)
Through portal bridging, Matrix rooms will automatically be created by the bot and bridged to the relevant Discord room. This is done by simply joining a room with a specific name pattern (`#_discord_<guildID>_<channlID>`).
Through portal bridging, Matrix rooms will automatically be created by the bot and bridged to the relevant Discord room. This is done by simply joining a room with a specific name pattern (`#_discord_<guildID>_<channelID>`).
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.
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.
If you want to disable portal bridging, set the following in`vars.yml`:
To disable portal bridging, add the following configuration to your`vars.yml` file:
1. To invite the bot to Discord, retrieve the invite link from the `{{ matrix_appservice_discord_config_path }}/invite_link` file on the server (this defaults to `/matrix/appservice-discord/config/invite_link`). You need to peek at the file on the server via SSH, etc., because it's not available via HTTP(S).
1. To invite the bot to Discord, retrieve the invite link from the `{{ matrix_appservice_discord_config_path }}/invite_link` file on the server (this defaults to `/matrix/appservice-discord/config/invite_link`). You need to peek at the file on the server via SSH, etc., because it's not available via HTTP(S).
@ -69,9 +108,24 @@ By default, you won't have Administrator access in rooms created by the bridge.
To adjust room access privileges or do various other things (change the room name subsequently, etc.), you'd wish to become an Administrator.
To adjust room access privileges or do various other things (change the room name subsequently, etc.), you'd wish to become an Administrator.
There's the Discord bridge's guide for [setting privileges on bridge managed rooms](https://github.com/Half-Shot/matrix-appservice-discord/blob/master/docs/howto.md#set-privileges-on-bridge-managed-rooms). To do the same with our container setup, run the following command on the server:
There's the Discord bridge's guide for [setting privileges on bridge managed rooms](https://github.com/matrix-org/matrix-appservice-discord/blob/master/docs/howto.md#set-privileges-on-bridge-managed-rooms). To do the same with our container setup, run the following command on the server:
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.
**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.
@ -6,7 +15,9 @@ The playbook can install and configure the [matrix-appservice-irc](https://githu
See the project's [documentation](https://github.com/matrix-org/matrix-appservice-irc/blob/master/HOWTO.md) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/matrix-org/matrix-appservice-irc/blob/master/HOWTO.md) to learn what it does and why it might be useful to you.
You'll need to use the following playbook configuration:
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
You then need to start a chat with `@irc_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
### 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-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`
`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, 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.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
matrix_appservice_kakaotalk_enabled:true
```
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
Take a look at:
-`roles/custom/matrix-bridge-appservice-kakaotalk/defaults/main.yml` for some variables that you can customize via your `vars.yml` file
-`roles/custom/matrix-bridge-appservice-kakaotalk/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_kakaotalk_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 `@kakaotalkbot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
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.
## 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-kakaotalk`.
### 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:
**Note**: bridging to [Slack](https://slack.com) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) bridge supported by the playbook.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
# Setting up Appservice Slack bridging (optional)
**Notes**:
- Bridging to [Slack](https://slack.com) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) and [mautrix-slack](configuring-playbook-bridge-mautrix-slack.md) bridges supported by the playbook.
- Currently (as of November, 2024) **this component is not available for new installation unless you have already created a classic Slack application** (which the bridge makes use of in order to enable bridging between Slack and Matrix), because the creation of classic Slack applications has been discontinued since June 4 2024. The author of the bridge claims [here](https://github.com/matrix-org/matrix-appservice-slack/issues/789#issuecomment-2172947787) that he plans to support the modern Slack application and until then "the best (and only) option for new installations is to use the webhook bridging".
The playbook can install and configure [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) for you.
The playbook can install and configure [matrix-appservice-slack](https://github.com/matrix-org/matrix-appservice-slack) for you.
See the project's [documentation](https://github.com/matrix-org/matrix-appservice-slack/blob/master/README.md) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/matrix-org/matrix-appservice-slack/blob/master/README.md) to learn what it does and why it might be useful to you.
## Setup Instructions:
## Prerequisites
loosely based on [this](https://github.com/matrix-org/matrix-appservice-slack#Setup)
### Create a Classic Slack App
1. Create a new Matrix room to act as the administration control room. Note its internal room ID. This can
First, you need to create a Classic Slack App [here](https://api.slack.com/apps?new_classic_app=1).
be done in Element by making a message, opening the options for that message and choosing "view source". The
room ID will be displayed near the top.
Name the app "matrixbot" (or anything else you'll remember). Select the team/workspace this app will belong to. Click on bot users and add a new bot user. We will use this account to bridge the the rooms.
2. Enable the bridge with the following configuration in your `vars.yml` file:
Then, click on Event Subscriptions and enable them and use the request url: `https://matrix.example.com/appservice-slack`.
Add the following events as `Bot User Events` and save:
- team_domain_change
- message.channels
- message.groups (if you want to bridge private channels)
- reaction_added
- reaction_removed
Next, click on "OAuth & Permissions" and add the following scopes:
- chat:write:bot
- users:read
- reactions:write
- files:write:user (if you want to bridge files)
**Note**: In order to make Slack files visible to Matrix users, this bridge will make Slack files visible to anyone with the url (including files in private channels). This is different than the current behavior in Slack, which only allows authenticated access to media posted in private channels. See MSC701 for details.
Click on "Install App" and "Install App to Workspace". Note the access tokens shown. You will need the Bot User OAuth Access Token and if you want to bridge files, the OAuth Access Token whenever you link a room.
### Create an administration control room on Matrix
Create a new Matrix room to act as the administration control room.
Note its internal room ID. This can be done in Element Web by sending a message, opening the options for that message and choosing "view source". The room ID will be displayed near the top.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
# See https://matrix-appservice-slack.readthedocs.io/en/latest/team_sync/
# matrix_appservice_slack_team_sync_enabled: true
```
```
3. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
### Extending the configuration
4. Invite the bridge bot user into the admin room:
```
There are some additional things you may wish to configure about the bridge.
/invite @slackbot:MY.DOMAIN
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.
Note that the bot's domain is your server's domain **without the `matrix.` prefix.**
## Installing
5. Create a Classic Slack App [here](https://api.slack.com/apps?new_classic_app=1).
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
Name the app "matrixbot" (or anything else you'll remember).
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
Select the team/workspace this app will belong to.
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
Click on bot users and add a new bot user. We will use this account to bridge the the rooms.
`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.
6. Click on Event Subscriptions and enable them and use the request url `https://matrix.DOMAIN/appservice-slack`. Then add the following events and save:
## Usage
Bot User Events:
To use the bridge, you need to send `/invite @slackbot:example.com` to invite the bridge bot user into the admin room.
- team_domain_change
If Team Sync is not enabled, for each channel you would like to bridge, perform the following steps:
- message.channels
- message.groups (if you want to bridge private channels)
- reaction_added
- reaction_removed
7. Click on OAuth & Permissions and add the following scopes:
- 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.
- chat:write:bot
- 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/`.
- users:read
- Issue a link command in the administration control room with these collected values as arguments:
- reactions:write
If you want to bridge files, also add the following:
- files:write:user
Note: In order to make Slack files visible to matrix users, this bridge will make Slack files visible to anyone with the url (including files in private channels). This is different than the current behavior in Slack, which only allows authenticated access to media posted in private channels. See MSC701 for details.
8. Click on Install App and Install App to Workspace. Note the access tokens shown. You will need the Bot User OAuth Access Token and if you want to bridge files, the OAuth Access Token whenever you link a room.
9. 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 !aBcDeF: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:MY.DOMAIN` for matrix.
* Determine the "channel ID" that Slack uses to identify the channel. You can see it when you open a given Slack channel in a browser. The URL reads like this: `https://app.slack.com/client/XXX/<the channel id>/details/`.
* Issue a link command in the administration control room with these collected values as arguments:
with file bridging:
with file bridging:
```
```
link --channel_id CHANNELID --room !the-matrix:room.id --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx --slack_user_token xoxp-xxxxxxxx-xxxxxxxxx-xxxxxxxx-xxxxxxxx
link --channel_id CHANNELID --room !qporfwt:example.com --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx --slack_user_token xoxp-xxxxxxxx-xxxxxxxxx-xxxxxxxx-xxxxxxxx
```
```
without file bridging:
without file bridging:
```
```
link --channel_id CHANNELID --room !the-matrix:room.id --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
link --channel_id CHANNELID --room !qporfwt:example.com --slack_bot_token xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
```
```
These arguments can be shortened to single-letter forms:
These arguments can be shortened to single-letter forms:
```
```
link -I CHANNELID -R !the-matrix:room.id -t xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
link -I CHANNELID -R !qporfwt:example.com -t xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxx
```
```
Other configuration options are available via the `matrix_appservice_slack_configuration_extension_yaml` variable.
### Unlinking
10. Unlinking
Channels can be unlinked again by sending this:
Channels can be unlinked again like this:
```
```
unlink --room !qporfwt:example.com
unlink --room !the-matrix:room.id
```
```
Unlinking doesn't only disconnect the bridge, but also makes the slackbot leave the bridged matrix room. So in case you want to re-link later, don't forget to re-invite the slackbot into this room again.
Unlinking doesn't only disconnect the bridge, but also makes the slackbot leave the bridged Matrix room. So in case you want to re-link later, don't forget to re-invite the slackbot into this room again.
## Troubleshooting
## Troubleshooting
* as always, check the logs:
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`.
`journalctl -fu matrix-appservice-slack`
* linking: "Room is now pending-name"
### Linking: "Room is now pending-name"
This typically means that you haven't used the correct slack channel id. Unlink the room and recheck 'Determine the "channel ID"' from above.
* Messages work from M to S, but not the other way around
This typically means that you haven't used the correct Slack channel ID. Unlink the room and recheck 'Determine the "channel ID"' from above.
Check you logs, if they say something like
`WARN SlackEventHandler Ignoring message from unrecognised slack channel id : %s (%s) <thechannelid><someotherid>`
### Messages work from Matrix to Slack, but not the other way around
then unlink your room, reinvite the bot and re-link it again. This may particularly hit you, if you tried to unsuccessfully link
Check the logs, and if you find the message like below, unlink your room, reinvite the bot and re-link it again.
your room multiple times without unlinking it after each failed attempt.
`WARN SlackEventHandler Ignoring message from unrecognised Slack channel ID : %s (%s) <thechannelID><someotherID>`
This may particularly hit you, if you tried to unsuccessfully link your room multiple times without unlinking it after each failed attempt.
The playbook can install and configure [matrix-appservice-webhooks](https://github.com/turt2live/matrix-appservice-webhooks) for you.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
Note: This bridge is no longer maintained. While not a 1:1 replacement, the bridge's author suggests taking a look at [matrix-hookshot](https://github.com/Half-Shot/matrix-hookshot) as a replacement, which can also be installed using [this playbook](configuring-playbook-bridge-hookshot.md).
# Setting up Appservice Webhooks bridging (optional, deprecated)
This bridge provides support for Slack-compatible webhooks.
**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.
Setup Instructions:
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.
loosely based on [this](https://github.com/turt2live/matrix-appservice-webhooks/blob/master/README.md)
See the project's [documentation](https://github.com/turt2live/matrix-appservice-webhooks/blob/master/README.md) to learn what it does and why it might be useful to you.
1. All you basically need is to adjust your `inventory/host_vars/matrix.<domain-name>/vars.yml`:
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
# As of Synapse 1.90.0, uncomment to enable the backwards compatibility (https://matrix-org.github.io/synapse/latest/upgrade#upgrading-to-v1900) that this bridge needs.
# Note: This deprecated method is considered insecure.
#
# matrix_synapse_configuration_extension_yaml: |
# use_appservice_legacy_authorization: true
```
```
2. In case you want to change the verbosity of logging via `journalctl -fu matrix-appservice-webhooks.service`
### Extending the configuration
you can adjust this in `inventory/host_vars/matrix.<domain-name>/vars.yml` as well.
*Note*: default value is: `info` and availabe log levels are : `info`, `verbose`
There are some additional things you may wish to configure about the bridge.
-`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. -->
3. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready.
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
4. If you're using the [Dimension Integration Manager](configuring-playbook-dimension.md), you can configure the Webhooks bridge by opening the Dimension integration manager -> Settings -> Bridges and selecting edit action for "Webhook Bridge". Press "Add self-hosted Bridge" button and populate "Provisioning URL" & "Shared Secret" values from `/matrix/appservice-webhooks/config/config.yaml` file's homeserver URL value and provisioning secret value, respectively.
`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.
5. Invite the bridge bot user to your room:
## Usage
- either with `/invite @_webhook:<domain.name>` (*Note*: Make sure you have administration permissions in your room)
To use the bridge, you need to invite the bridge bot user to your room in either way.
- or simply add the bridge bot to a private channel (personal channels imply you being an administrator)
- Send `/invite @_webhook:example.com` (**Note**: Make sure you have administration permissions in your room)
- Add the bridge bot to a private channel (personal channels imply you being an administrator)
You then need to send a message to the bridge bot to receive a private message including the webhook link:
6. Send a message to the bridge bot in order to receive a private message including the webhook link.
```
```
!webhook
!webhook
```
```
7.The JSON body for posting messages will have to look like this:
The JSON body for posting messages will have to look like this:
<the webhook link you've gotten from the bridge bot>
```
### Setting Webhooks with Dimension integration manager
If you're using the [Dimension integration manager](configuring-playbook-dimension.md), you can configure the Webhooks bridge with it.
To configure it, open the Dimension integration manager, and go to "Settings" and "Bridges", then select edit action for "Webhook Bridge".
On the UI, press "Add self-hosted Bridge" button and populate "Provisioning URL" and "Shared Secret" values from `/matrix/appservice-webhooks/config/config.yaml` file's homeserver URL value and provisioning secret value, respectively.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-appservice-webhooks`.
### Increase logging verbosity
The default logging level for this component is `info`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
The playbook can install and configure [beeper-linkedin](https://gitlab.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
SPDX-License-Identifier: AGPL-3.0-or-later
-->
See the project's [documentation](https://gitlab.com/beeper/linkedin/-/blob/master/README.md) to learn what it does and why it might be useful to you.
# Setting up Beeper Linkedin bridging (optional)
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:
```yaml
```yaml
matrix_beeper_linkedin_enabled:true
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.
bridge:
encryption:
**Note**: when following the guide to configure the bridge, make sure to replace `_mautrix_SERVICENAME_` in the variable names with `_beeper_linkedin_`.
allow: true
default: 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. -->
You may wish to look at `roles/matrix-bridge-beeper-linkedin/templates/config.yaml.j2` to find other things you would like to configure.
## Set up Double Puppeting
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Method 1: automatically, by enabling Shared Secret Auth
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
`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
## Usage
You then need to start a chat with `@linkedinbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
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), 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
## 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
### 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.
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, 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 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`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
## Usage
To use the bridge, you need to start a chat with `@skypebridgebot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-go-skype-bridge`.
### Increase logging verbosity
The default logging level for this component is `warn`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
# 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.
**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 [README](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).
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)
Below are the common configuration options that you may want to set, exhaustive list is in [the bridge's defaults var file](../roles/matrix-bridge-heisenbridge/defaults/main.yml).
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.
At a minimum, you only need to enable the bridge to get it up and running (`inventory/host_vars/matrix.DOMAIN/vars.yml`):
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:
```yaml
```yaml
matrix_heisenbridge_enabled:true
matrix_heisenbridge_enabled:true
# set owner (optional)
# Setting the owner is optional as the first local user to DM `@heisenbridge:example.com` will be made the owner.
matrix_heisenbridge_owner:"@you:your-homeserver"
# If you are not using a local user you must set it as otherwise you can't DM it at all.
# to enable identd on host port 113/TCP (optional)
# Uncomment to enable identd on host port 113/TCP (optional)
matrix_heisenbridge_identd_enabled:true
# matrix_heisenbridge_identd_enabled: true
```
```
That's it! A registration file is automatically generated during the setup phase.
### Adjusting the Heisenbridge URL (optional)
Setting the owner is optional as the first local user to DM `@heisenbridge:your-homeserver` will be made the owner.
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.
If you are not using a local user you must set it as otherwise you can't DM it at all.
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`.
When setting, replace `example.com` with your own.
### Extending the 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
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.
## Usage
## Usage
After the bridge is successfully running just DM `@heisenbridge:your-homeserver` to start setting it up.
To use the bridge, you need to start a chat with `@heisenbridge:example.com` (where `example.com` is your base domain, not the `matrix.` domain). If the bridge ignores you and a DM is not accepted then the owner setting may be wrong.
Help is available for all commands with the `-h` switch.
Help is available for all commands with the `-h` switch.
If the bridge ignores you and a DM is not accepted then the owner setting may be wrong.
You can also learn the basics by watching [this demonstration video](https://www.youtube.com/watch?v=nQk1Bp4tk4I).
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.
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.
The playbook can install and configure [matrix-hookshot](https://github.com/matrix-org/matrix-hookshot) for you.
Hookshot can bridge [Webhooks](https://en.wikipedia.org/wiki/Webhook) from software project management services such as GitHub, GitLab, JIRA, and Figma, as well as generic webhooks.
Hookshot can bridge [Webhooks](https://en.wikipedia.org/wiki/Webhook) from software project management services such as GitHub, GitLab, Jira, and Figma, as well as generic webhooks.
See the project's [documentation](https://matrix-org.github.io/matrix-hookshot/hookshot.html) to learn what it does in detail and why it might be useful to you.
See the project's [documentation](https://matrix-org.github.io/matrix-hookshot/latest/hookshot.html) to learn what it does and why it might be useful to you.
Note: the playbook also supports [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), which however is soon to be archived by its author and to be replaced by hookshot.
**Note**: the playbook also supports [matrix-appservice-webhooks](configuring-playbook-bridge-appservice-webhooks.md), which however was deprecated by its author.
## Setup Instructions
## Prerequisites
Refer to the [official instructions](https://matrix-org.github.io/matrix-hookshot/setup.html) to learn what the individual options do.
### Download GitHub app private key (optional)
1. For each of the services (GitHub, GitLab, Jira, Figma, generic webhooks) fill in the respective variables `matrix_hookshot_service_*` listed in [main.yml](/roles/matrix-bridge-hookshot/defaults/main.yml) as required.
If you're setting up the GitHub bridge, you need to create your GitHub app, and generate a private key file of it.
2. Take special note of the `matrix_hookshot_*_enabled` variables. Services that need no further configuration are enabled by default (GitLab, Generic), while you must first add the required configuration and enable the others (GitHub, Jira, Figma).
3. If you're setting up the GitHub bridge, you'll need to generate and download a private key file after you created your GitHub app. Copy the contents of that file to the variable `matrix_hookshot_github_private_key` so the playbook can install it for you, or use one of the [other methods](#manage-github-private-key-with-matrix-aux-role) explained below.
4. If you've already installed Matrix services using the playbook before, you'll need to re-run it (`--tags=setup-all,start`). If not, proceed with [configuring other playbook services](configuring-playbook.md) and then with [Installing](installing.md). Get back to this guide once ready. Hookshot can be set up individually using the tag `setup-hookshot`.
5. Refer to [Hookshot's official instructions](https://matrix-org.github.io/matrix-hookshot/latest/usage.html) to start using the bridge. **Important:** Note that the different listeners are bound to certain paths which might differ from those assumed by the hookshot documentation, see [URLs for bridges setup](urls-for-bridges-setup) below.
Other configuration options are available via the `matrix_hookshot_configuration_extension_yaml` and `matrix_hookshot_registration_extension_yaml` variables, see the comments in [main.yml](/roles/matrix-bridge-hookshot/defaults/main.yml) for how to use them.
You need to download the private key file, if you will install the file manually or with the `aux` role. For details, see [the section below](#manage-github-private-key-with-aux-role).
## Adjusting the playbook configuration
Add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file. Make sure to replace `GITHUB_PRIVATE_KEY_HERE` with the one created [above](#download-github-app-private-key).
For each of the services (GitHub, GitLab, Jira, Figma, and generic webhooks) fill in the respective variables `matrix_hookshot_service_*` listed in [main.yml](../roles/custom/matrix-bridge-hookshot/defaults/main.yml) as required.
Take special note of the `matrix_hookshot_*_enabled` variables. Services that need no further configuration are enabled by default (GitLab and generic webhooks), while you must first add the required configuration and enable the others (GitHub, Jira, and Figma).
### Extending the configuration
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.
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-service hookshot` or `just setup-all`
`just install-service hookshot` is useful for maintaining your setup quickly when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note `just setup-all` runs the `ensure-matrix-users-created` tag too.
## Usage
To use the bridge, you need to create a room and invite the Hookshot bot (`@hookshot:example.com`) to it.
Make sure the bot is able to send state events (usually the Moderator power level in clients).
Send `!hookshot help` to the bot to see the available commands.
Refer to [Hookshot's documentation](https://matrix-org.github.io/matrix-hookshot/latest/usage.html) for more details about using the bridge's various features.
💡 **Note**: the different listeners are bound to certain paths which might differ from those assumed by the hookshot documentation. See [URLs for bridges setup](#urls-for-bridges-setup) below.
### Reset crypto store
Should the crypto store be corrupted, you can reset it by executing this Ansible playbook with the tag `reset-hookshot-encryption` added:
See also `matrix_hookshot_matrix_nginx_proxy_configuration` in [init.yml](/roles/matrix-bridge-hookshot/tasks/init.yml).
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/matrix-bridge-hookshot/defaults/main.yml) in detail for more info.
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.
### Manage GitHub Private Key with matrix-aux role
### Manage GitHub Private Key with aux role
The GitHub bridge requires you to install a private key file. This can be done in multiple ways:
The GitHub bridge requires you to install a private key file. This can be done in multiple ways:
- copy the *contents* of the downloaded file and set the variable `matrix_hookshot_github_private_key` to the contents (see example in [main.yml](/roles/matrix-bridge-hookshot/defaults/main.yml)).
- 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 `matrix-aux` role to copy the file from an arbitrary path on your ansible client to the correct path on the server.
To use `matrix-aux`, make sure the `matrix_hookshot_github_private_key` variable is empty. Then add to `matrix-aux` configuration like this:
- copy the *contents* of the downloaded file and set the variable `matrix_hookshot_github_private_key` to the contents (see example in [main.yml](../roles/custom/matrix-bridge-hookshot/defaults/main.yml)).
- 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 `vars.yml` file:
For more info see the documentation in the [matrix-aux base configuration file](/roles/matrix-aux/defaults/main.yml).
### Provisioning API
For more information, see the documentationin the [default configuration of the aux role](https://github.com/mother-of-all-self-hosting/ansible-role-aux/blob/main/defaults/main.yml).
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
If metrics are enabled, they will be automatically available in the builtin Prometheus and Grafana, but you need to set up your own Dashboard for now. If additionally metrics proxying for use with external Prometheus is enabled (`matrix_nginx_proxy_proxy_synapse_metrics`), hookshot metrics will also be available (at `matrix_hookshot_metrics_endpoint`, default `/hookshot/metrics`, on the stats subdomain) and with the same password. See also [the Prometheus and Grafana docs](../configuring-playbook-prometheus-grafana.md).
### Collision with matrix-appservice-webhooks
### 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_user_id_prefix: '_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.
The playbook can install and configure [matrix-sms-bridge](https://github.com/benkuly/matrix-sms-bridge) for you.
See the project page to learn what it does and why it might be useful to 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
To enable the bridge just use the following
The bridge uses [android-sms-gateway-server](https://github.com/RebekkaMa/android-sms-gateway-server). You need to configure it first.
playbook configuration:
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_sms_bridge_enabled:true
matrix_sms_bridge_enabled:true
# (optional but recommended) a room id to a default room
# (optional but recommended) a room ID to a default room
matrix_sms_bridge_default_room:""
matrix_sms_bridge_default_room:""
# (optional but recommended) configure your server location
# (optional but recommended) configure your server location
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`
`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
## Usage
Read the [user guide](https://github.com/benkuly/matrix-sms-bridge/blob/master/README.md#user-guide) to see how this bridge works.
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.
The playbook can install and configure [mautrix-discord](https://github.com/mautrix/discord) for you.
See the project's [documentation](https://docs.mau.fi/bridges/go/discord/index.html) to learn what it does and why it might be useful to you.
## Prerequisites
There are 2 ways to login to discord using this bridge, either by [scanning a QR code](#method-1-login-using-qr-code-recommended) using the Discord mobile app **or** by using a [Discord token](#method-2-login-using-discord-token-not-recommended).
If this is a dealbreaker for you, consider using one of the other Discord bridges supported by the playbook: [mx-puppet-discord](configuring-playbook-bridge-mx-puppet-discord.md) or [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md). These come with their own complexity and limitations, however, so we recommend that you proceed with this one if possible.
### Enable Appservice Double Puppet or Shared Secret Auth (optional)
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:
```yaml
matrix_mautrix_discord_enabled:true
```
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
<!-- 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
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 `@discordbot: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/discord/authentication.html).
After logging in, the bridge will create portal rooms for some recent direct messages.
### Bridge guilds
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.
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.
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.
## Troubleshooting
As with all other services, you can find the logs in [systemd-journald](https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html) by logging in to the server with SSH and running `journalctl -fu matrix-mautrix-discord`.
### 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 Mautrix Facebook bridging (optional, deprecated)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**Note**: This bridge has been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge, which can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-messenger.md). Consider using that bridge instead of this one.
The playbook can install and configure [mautrix-facebook](https://github.com/mautrix/facebook) for you.
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.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mautrix_facebook_enabled:true
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.
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.
bridge:
encryption:
## Installing
allow: true
default: true
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. -->
You may wish to look at `roles/matrix-bridge-mautrix-facebook/templates/config.yaml.j2` to find other things you would like to configure.
## Set up Double Puppeting
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Method 1: automatically, by enabling Shared Secret Auth
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Method 2: manually, by asking each user to provide a working access token
**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging (see [Usage](#usage)).
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. You can use the following command:
- 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
`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
## Usage
You then need to start a chat with `@facebookbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
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.
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), if you haven't already done so.
## Troubleshooting
## 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
### Facebook rejecting login attempts and forcing you to change password
If your Matrix server is in a wildly different location than where you usually use your Facebook account from, the bridge's login attempts may be outright rejected by Facebook. Along with that, Facebook may even force you to change the account's password.
If 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.
@ -82,8 +87,8 @@ The easiest way to do this may be to use [sshuttle](https://sshuttle.readthedocs
Example command for proxying your traffic through the Matrix server:
Example command for proxying your traffic through the Matrix server:
```
```sh
sshuttle -r root@matrix.DOMAIN:22 0/0
sshuttle -r root@matrix.example.com:22 0/0
```
```
Once connected, you should be able to verify that you're browsing the web through the Matrix server's IP by checking [icanhazip](https://icanhazip.com/).
Once connected, you should be able to verify that you're browsing the web through the Matrix server's IP by checking [icanhazip](https://icanhazip.com/).
@ -91,3 +96,5 @@ Once connected, you should be able to verify that you're browsing the web throug
Then proceed to log in to [Facebook/Messenger](https://www.facebook.com/).
Then proceed to log in to [Facebook/Messenger](https://www.facebook.com/).
Once logged in, proceed to [set up bridging](#usage).
Once logged in, proceed to [set up bridging](#usage).
If that doesn't work, enable 2FA (see: [Facebook help page on enabling 2FA](https://www.facebook.com/help/148233965247823)) and try to login again with a new password, and entering the 2FA code when prompted, it may take more then one try, in between attempts, check facebook.com to see if they are requiring another password change
# 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.
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_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`
`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).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/gmessages/authentication.html).
After logging in, the bridge will create portal rooms for recent chats.
## 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-gmessages`.
### 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 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.
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.
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.
To enable the [Google Chat](https://chat.google.com/) bridge just use the following playbook configuration:
## 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.
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 [Google Chat](https://chat.google.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mautrix_googlechat_enabled:true
matrix_mautrix_googlechat_enabled:true
```
```
### Extending the configuration
## Set up Double Puppeting
There are some additional things you may wish to configure about the bridge.
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
<!-- 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.
### Method 1: automatically, by enabling Shared Secret Auth
## Installing
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
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.
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
- send the access token to the bot. Example: `login-matrix MATRIX_ACCESS_TOKEN_HERE`
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
- make sure you don't log out the `Mautrix-googlechat` device some time in the future, as that would break the Double Puppeting feature
`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
## Usage
Once the bot is enabled you need to start a chat with `googlechat bridge bot` with handle `@googlechatbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` 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`.
After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
### 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 [Mautrix Hangouts Bridge](https://mau.dev/mautrix/hangouts) is no longer maintained. It has changed to a [Google Chat Bridge](https://github.com/mautrix/googlechat). Setup instructions for the Google Chat Bridge can be [found here](configuring-playbook-bridge-mautrix-googlechat.md).
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.
To enable the [Google Hangouts](https://hangouts.google.com/) bridge just use the following playbook configuration:
You may wish to use the [Google Chat bridge](https://github.com/mautrix/googlechat) instead.
## Uninstalling the bridge manually
```yaml
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:
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Method 1: automatically, by enabling Shared Secret Auth
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Method 2: manually, by asking each user to provide a working access token
**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging (see [Usage](#usage)).
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. You can use the following command:
- 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
## Usage
Once the bot is enabled you need to start a chat with `Hangouts bridge bot` with handle `@hangoutsbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` 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).
After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
# Setting up Mautrix Instagram bridging (optional, deprecated)
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**Note**: This bridge has been deprecated in favor of the [mautrix-meta](https://github.com/mautrix/meta) Messenger/Instagram bridge, which can be [installed using this playbook](configuring-playbook-bridge-mautrix-meta-instagram.md). Consider using that bridge instead of this one.
The playbook can install and configure [mautrix-instagram](https://github.com/mautrix/instagram) for you.
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
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mautrix_instagram_enabled:true
matrix_mautrix_instagram_enabled:true
```
```
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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
## Usage
You then need to start a chat with `@instagrambot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
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).
## Prerequisites
### Migrating from the old mautrix-instagram bridge
If you've been using the [mautrix-instagram](./configuring-playbook-bridge-mautrix-instagram.md) bridge, **you'd better get rid of it first** or the 2 bridges will be in conflict:
- both trying to use `@instagrambot:example.com` as their username. This conflict may be resolved by adjusting `matrix_mautrix_instagram_appservice_bot_username` or `matrix_mautrix_meta_instagram_appservice_username`
- both trying to bridge the same DMs
To do so, send a `clean-rooms` command to the management room with the old bridge bot (`@instagrambot:example.com`). It gives you a list of portals and groups of portals you may purge. Proceed with sending commands like `clean recommended`, etc.
Then, consider disabling the old bridge in your configuration, so it won't recreate the portals when you receive new messages.
### Enable Appservice Double Puppet (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) 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_meta_instagram_enabled:true
```
Before proceeding to [re-running the playbook](./installing.md), you may wish to adjust the configuration further. See below.
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed. Note these shortcuts run the `ensure-matrix-users-created` tag too.
## Usage
To use the bridge, you need to start a chat with `@instagrambot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/meta/authentication.html).
After logging in, the bridge will sync recent chats.
## 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-meta-instagram`.
### Increase logging verbosity
The default logging level for this component is `warn`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
```yaml
# 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).
## Prerequisites
### Migrating from the old mautrix-facebook bridge
If you've been using the [mautrix-facebook](./configuring-playbook-bridge-mautrix-facebook.md) bridge, it's possible to migrate the database using [instructions from the bridge documentation](https://docs.mau.fi/bridges/go/meta/facebook-migration.html) (advanced).
Then you may wish to get rid of the Facebook bridge. To do so, send a `clean-rooms` command to the management room with the old bridge bot (`@facebookbot:example.com`). It gives you a list of portals and groups of portals you may purge. Proceed with sending commands like `clean recommended`, etc.
Then, consider disabling the old bridge in your configuration, so it won't recreate the portals when you receive new messages.
**Note**: the user ID of the new bridge bot is `@messengerbot:example.com`, not `@facebookbot:example.com`. After disabling the old bridge, its bot user will stop responding to a command.
### Enable Appservice Double Puppet (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) 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_meta_messenger_enabled:true
```
Before proceeding to [re-running the playbook](./installing.md), you may wish to adjust the configuration further. See below.
### Bridge mode
As mentioned above, the [mautrix-meta](https://github.com/mautrix/meta) bridge supports multiple modes of operation.
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
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.).
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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 `@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 can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/meta/authentication.html).
After logging in, the bridge will sync recent chats.
**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.
## 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-meta-messenger`.
### Increase logging verbosity
The default logging level for this component is `warn`. If you want to increase the verbosity, add the following configuration to your `vars.yml` file and re-run the playbook:
```yaml
# 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.
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.
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.
**Note/Prerequisite**: If you're running with the Postgres database server integrated by the playbook (which is the default), you don't need to do anything special and can easily proceed with installing. However, if you're [using an external Postgres server](configuring-playbook-external-postgres.md), you'd need to manually prepare a Postgres database for this bridge and adjust the variables related to that (`matrix_mautrix_signal_database_*`).
## Prerequisites (optional)
Use the following playbook configuration:
### Prepare Postgres database on external Postgres server
If you're running with the Postgres database server integrated by the playbook (which is the default), you don't need to do anything special and can easily proceed with installing.
However, if you're [using an external Postgres server](configuring-playbook-external-postgres.md), you'd need to manually prepare a Postgres database for this bridge and adjust the variables related to that (`matrix_mautrix_signal_database_*`).
### 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
```yaml
matrix_mautrix_signal_enabled:true
matrix_mautrix_signal_enabled:true
```
```
There are some additional things you may wish to configure about the bridge before you continue.
### 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_signal_relaybot_enabled:true
```
If you want to activate the relay bot in a room, use `!signal set-relay`.
Use `!signal unset-relay` to deactivate.
By default, any user on your homeserver will be able to use the bridge.
If you enable the relay bot functionality, it will relay every user's messages in a portal room - no matter which homeserver they're from.
Different levels of permission can be granted to users:
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.
* relay - Allowed to be relayed through the bridge, no access to commands;
## Installing
* user - Use the bridge with puppeting;
* admin - Use and administer the bridge.
The permissions are following the sequence: nothing <relay<user<admin.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
Thedefaultpermissionsaresetasfollows:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
`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
## Usage
Youthenneedtostarta chat with`@signalbot:YOUR_DOMAIN`(where`YOUR_DOMAIN`is your base domain,not the`matrix.`domain).
To use the bridge, you need to start a chatwith `@signalbot:example.com` (where `example.com` isyourbasedomain, not the `matrix.` domain).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/signal/authentication.html).
After logging in, the bridge will bridge chats as you receive messages.
**Note**: Signal does not support any kind of message history (even on official apps), so the bridge won't backfill any 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-signal`.
### 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:
<sup>Refer the common guide for configuring mautrix bridges: [Setting up a Generic Mautrix Bridge](configuring-playbook-bridge-mautrix-bridges.md)</sup>
**Note**: bridging to [Slack](https://slack.com/) can also happen via the [mx-puppet-slack](configuring-playbook-bridge-mx-puppet-slack.md) and [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) bridges supported by the playbook.
- For using as a Bot we recommend the [Appservice Slack](configuring-playbook-bridge-appservice-slack.md), because it supports plumbing. Note that it is not available for new installation unless you have already created a classic Slack application, because the creation of classic Slack applications, which this bridge makes use of, has been discontinued.
- For personal use with a slack account we recommend the `mautrix-slack` bridge (the one being discussed here), because it is the most fully-featured and stable of the 3 Slack bridges supported by the playbook.
The playbook can install and configure [mautrix-slack](https://github.com/mautrix/slack) for you.
See the project's [documentation](https://docs.mau.fi/bridges/go/slack/index.html) to learn what it does and why it might be useful to you.
See the [features and roadmap](https://github.com/mautrix/slack/blob/main/ROADMAP.md) for more information.
## Prerequisites
For using this bridge, you would need to authenticate by **providing your username and password** (legacy) or by using a **token login**. See more information in the [docs](https://docs.mau.fi/bridges/go/slack/authentication.html).
Note that neither of these methods are officially supported by Slack. [matrix-appservice-slack](configuring-playbook-bridge-appservice-slack.md) uses a Slack bot account which is the only officially supported method for bridging a Slack channel.
### Enable Appservice Double Puppet (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) 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_slack_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. Note these shortcuts run the `ensure-matrix-users-created` tag too.
## Usage
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).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/slack/authentication.html).
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.
## 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-slack`.
### 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:
<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.
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.
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.
You'll need to obtain API keys from [https://my.telegram.org/apps](https://my.telegram.org/apps) and then use the following playbook configuration:
## 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.
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
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`.
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Enable relay-bot (optional)
### Method 1: automatically, by enabling Shared Secret Auth
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:
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Method 2: manually, by asking each user to provide a working access token
**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging.
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. You can use the following command:
- send `login-matrix` to the bot and follow instructions about how to send the access token to it
- make sure you don't log out the `Mautrix-Telegram` device some time in the future, as that would break the Double Puppeting feature
## Usage
You then need to start a chat with `@telegrambot:YOUR_DOMAIN` (where `YOUR_DOMAIN` 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, use the following additional playbook configuration:
You might also want to give permissions to administrate the bot:
### Configure a user as an administrator of the bridge (optional)
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
### 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:
There are some additional things you may wish to configure about the bridge.
<!-- 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
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 `@telegrambot: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/python/telegram/authentication.html).
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.
## 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.
**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.
The playbook can install and configure [mautrix-twitter](https://github.com/mautrix/twitter) for you.
See the project's [documentation](https://github.com/mautrix/twitter) to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/mautrix/twitter/blob/master/README.md) to learn what it does and why it might be useful to you.
## 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
```yaml
matrix_mautrix_twitter_enabled:true
matrix_mautrix_twitter_enabled:true
```
```
### Extending the configuration
## Set up Double Puppeting
There are some additional things you may wish to configure about the bridge.
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
<!-- 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.
### Method 1: automatically, by enabling Shared Secret Auth
## Installing
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
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.
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
### Method 2: manually, by asking each user to provide a working access token
The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
This method is currently not available for the Mautrix-Twitter bridge, but is on the [roadmap](https://github.com/mautrix/twitter/blob/master/ROADMAP.md) under Misc/Manual login with `login-matrix`
`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
## Usage
1. You then need to start a chat with `@twitterbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
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).
2. Send login-cookie to start the login. The bot should respond with instructions on how to proceed.
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).
After successfully enabling bridging, you may wish to [set up Double Puppeting](#set-up-double-puppeting), if you haven't already done so.
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-twitter`.
### 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:
<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.
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.
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.
Use the following playbook configuration:
## 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.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#set-up-double-puppeting-optional) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about setting up Double Puppeting.
**Note**: double puppeting with the Shared Secret Auth works at the time of writing, but is deprecated and will stop working in the future.
## Adjusting the playbook configuration
To enable the bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mautrix_whatsapp_enabled:true
matrix_mautrix_whatsapp_enabled:true
```
```
Whatsapp multidevice beta is required, now it is enough if Whatsapp is connected to the Internet every 2 weeks.
## Enable backfilling history
### Extending the configuration
This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
Note that as of Synapse 1.46, there are still some bugs with the implementation, especially if using event persistence workers.
Use the following playbook configuration:
```yaml
There are some additional things you may wish to configure about the bridge.
matrix_synapse_configuration_extension_yaml:|
experimental_features:
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.
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
bridge:
history_sync:
<!-- 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`
If you'd like to use [Double Puppeting](https://docs.mau.fi/bridges/general/double-puppeting.html) (hint: you most likely do), you have 2 ways of going about it.
### Method 1: automatically, by enabling Shared Secret Auth
The bridge will automatically perform Double Puppeting if you enable [Shared Secret Auth](configuring-playbook-shared-secret-auth.md) for this playbook.
This is the recommended way of setting up Double Puppeting, as it's easier to accomplish, works for all your users automatically, and has less of a chance of breaking in the future.
### Method 2: manually, by asking each user to provide a working access token
**Note**: This method for enabling Double Puppeting can be configured only after you've already set up bridging (see [Usage](#usage)).
When using this method, **each user** that wishes to enable Double Puppeting needs to follow the following steps:
- retrieve a Matrix access token for yourself. You can use the following command:
- 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
`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
## Usage
You then need to start a chat with `@whatsappbot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base domain, not the `matrix.` domain).
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).
You can then follow instructions on the bridge's [official documentation on Authentication](https://docs.mau.fi/bridges/go/whatsapp/authentication.html).
Approximately in a minute after logging in, the bridge will create portal rooms for recent chats.
**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.
## 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-whatsapp`.
### 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 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:
```yaml
matrix_mautrix_wsproxy_enabled:true
matrix_mautrix_androidsms_appservice_token:'secret token from bridge'
matrix_mautrix_androidsms_homeserver_token:'secret token from bridge'
matrix_mautrix_imessage_appservice_token:'secret token from bridge'
matrix_mautrix_imessage_homeserver_token:'secret token from bridge'
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 (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 `vars.yml` file:
```yaml
# Change the default hostname
matrix_mautrix_wsproxy_hostname:ws.example.com
```
After changing the domain, **you may need to adjust your DNS** records to point the wsproxy domain to the Matrix server.
### Extending the configuration
There are some additional things you may wish to configure about the bridge.
See [this section](configuring-playbook-bridge-mautrix-bridges.md#extending-the-configuration) on the [common guide for configuring mautrix bridges](configuring-playbook-bridge-mautrix-bridges.md) for details about variables that you can customize and the bridge's default configuration, including [bridge permissions](configuring-playbook-bridge-mautrix-bridges.md#configure-bridge-permissions-optional), [encryption support](configuring-playbook-bridge-mautrix-bridges.md#enable-encryption-optional), [relay mode](configuring-playbook-bridge-mautrix-bridges.md#enable-relay-mode-optional), [bot's username](configuring-playbook-bridge-mautrix-bridges.md#set-the-bots-username-optional), etc.
## Installing
After configuring the playbook 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.
## Usage
Follow the [mautrix-imessage documentation](https://docs.mau.fi/bridges/go/imessage/index.html) for running `android-sms` and/or `matrix-imessage` on your device(s).
## 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`.
**Note**: bridging to [Discord](https://discordapp.com/) can also happen via the [matrix-appservice-discord](configuring-playbook-bridge-appservice-discord.md) bridge supported by the playbook.
SPDX-License-Identifier: AGPL-3.0-or-later
-->
The playbook can install and configure
# Setting up MX Puppet Discord bridging (optional)
[mx-puppet-discord](https://github.com/matrix-discord/mx-puppet-discord) for you.
See the project page to learn what it does and why it might be useful to you.
**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.
**Note**: we actually use the [Beeper](https://www.beeper.com/)-maintained [fork of mx-puppet-discord](https://gitlab.com/beeper/mx-puppet-monorepo), because `matrix-discord/mx-puppet-discord` is a low-quality and poorly maintained project.
The playbook can install and configure [mx-puppet-discord](https://gitlab.com/mx-puppet/discord/mx-puppet-discord) for you.
To enable the [Discord](https://discordapp.com/) bridge just use the following
See the project's [documentation](https://gitlab.com/mx-puppet/discord/mx-puppet-discord/blob/master/README.md) to learn what it does and why it might be useful to you.
playbook configuration:
## Adjusting the playbook configuration
To enable the [Discord](https://discordapp.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mx_puppet_discord_enabled:true
matrix_mx_puppet_discord_enabled:true
```
```
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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
## Usage
Once the bot is enabled you need to start a chat with `Discord Puppet Bridge` with
To use the bridge, you need to start a chat with `Discord Puppet Bridge` with the handle `@_discordpuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
the handle `@_discordpuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
Three authentication methods are available, Legacy Token, OAuth and xoxc token.
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-discord [documentation](https://gitlab.com/mx-puppet/discord/mx-puppet-discord) for more information about how to configure the bridge.
See mx-puppet-discord [documentation](https://github.com/matrix-discord/mx-puppet-discord)
for more information about how to configure the bridge.
Once logged in, send `list` to the bot user to list the available rooms.
Once logged in, send `list` to the bot user to list the available rooms.
Clicking rooms in the list will result in you receiving an invitation to the
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
bridged room.
Also send `help` to the bot to see the commands available.
Send `help` to the bot to see the available commands.
[mx-puppet-groupme](https://gitlab.com/robintown/mx-puppet-groupme) for you.
-->
See the project page to learn what it does and why it might be useful to you.
# Setting up MX Puppet GroupMe bridging (optional)
To enable the [GroupMe](https://groupme.com/) bridge just use the following
The playbook can install and configure [mx-puppet-groupme](https://gitlab.com/xangelix-pub/matrix/mx-puppet-groupme) for you.
playbook configuration:
See the project's [documentation](https://gitlab.com/xangelix-pub/matrix/mx-puppet-groupme/blob/master/README.md) to learn what it does and why it might be useful to you.
## Adjusting the playbook configuration
To enable the [GroupMe](https://groupme.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mx_puppet_groupme_enabled:true
matrix_mx_puppet_groupme_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 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
## Usage
Once the bot is enabled you need to start a chat with `GroupMe Puppet Bridge` with
To use the bridge, you need to start a chat with `GroupMe Puppet Bridge` with the handle `@_groupmepuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
the handle `@_groupmepuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
One authentication method is available.
One authentication method is available.
@ -30,7 +48,6 @@ link <access token>
Once logged in, send `listrooms` to the bot user to list the available rooms.
Once logged in, send `listrooms` to the bot user to list the available rooms.
Clicking rooms in the list will result in you receiving an invitation to the
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
bridged room.
Also send `help` to the bot to see the commands available.
Send `help` to the bot to see the available commands.
[mx-puppet-instagram](https://github.com/Sorunome/mx-puppet-instagram) for you.
-->
# 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.
This allows you to bridge Instagram DirectMessages into Matrix.
This allows you to bridge Instagram DirectMessages into Matrix.
To enable the [Instagram](https://www.instagram.com/) bridge just use the following
## Adjusting the playbook configuration
playbook configuration:
To enable the [Instagram](https://www.instagram.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mx_puppet_instagram_enabled:true
matrix_mx_puppet_instagram_enabled:true
```
```
## Installing
After configuring the playbook, run it with [playbook tags](playbook-tags.md) as below:
<!-- NOTE: let this conservative command run (instead of install-all) to make it clear that failure of the command means something is clearly broken. -->
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
## Usage
Once the bot is enabled, you need to start a chat with `Instagram Puppet Bridge` with
To use the bridge, you need to start a chat with `Instagram Puppet Bridge` with the handle `@_instagrampuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
the handle `@_instagrampuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
Send `link <username> <password>` to the bridge bot to link your instagram account.
Send `link <username> <password>` to the bridge bot to link your instagram account.
@ -32,5 +48,4 @@ For double-puppeting, you probably want to issue these commands:
If you are linking only one Instagram account, your `$puppetId` is probably 1, but use the `list` command find out.
If you are linking only one Instagram account, your `$puppetId` is probably 1, but use the `list` command find out.
The`help`command shows which commands are available, though at the time of writing, not every command is fully implemented.
Send`help`to the bot to see the available commands. At the time of writing, not every command is fully implemented.
[mx-puppet-skype](https://github.com/Sorunome/mx-puppet-skype) for you.
-->
See the project page to learn what it does and why it might be useful to you.
# Setting up MX Puppet Skype bridging (optional, removed)
To enable the [Skype](https://www.skype.com/) bridge just use the following
🪦 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.
playbook configuration:
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.
```yaml
matrix_mx_puppet_skype_enabled:true
```
## Usage
Once the bot is enabled you need to start a chat with `Skype Puppet Bridge` with
the handle `@_skypepuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
Send `link <username> <password>` to the bridge bot to link your skype account.
Once logged in, send `list` to the bot user to list the available rooms.
Clicking rooms in the list will result in you receiving an invitation to the
bridged room.
Also send `help` to the bot to see the commands available.
The playbook can install and configure [Beeper](https://www.beeper.com/)-maintained fork of
# Setting up MX Puppet Slack bridging (optional)
[mx-puppet-slack](https://gitlab.com/beeper/mx-puppet-monorepo) for you.
See the project page to learn what it does and why it might be useful to you.
**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.
## Setup
The playbook can install and configure [mx-puppet-slack](https://gitlab.com/mx-puppet/slack/mx-puppet-slack) for you.
To enable the [Slack](https://slack.com/) bridge:
See the project's [documentation](https://gitlab.com/mx-puppet/slack/mx-puppet-slack/blob/master/README.md) to learn what it does and why it might be useful to you.
instructions to create a new Slack app, setting the redirect URL to
Follow the [OAuth credentials](https://gitlab.com/mx-puppet/slack/mx-puppet-slack#option-2-oauth) instructions to create a new Slack app, setting the redirect URL to`https://matrix.example.com/slack/oauth`.
`https://matrix.YOUR_DOMAIN/slack/oauth`.
2. Update your `vars.yml` with the following:
## Adjusting the playbook configuration
```yaml
matrix_mx_puppet_slack_enabled: true
To enable the [Slack](https://slack.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
# Client ID must be quoted so YAML does not parse it as a float.
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
## Usage
Once the bot is enabled you need to start a chat with `Slack Puppet Bridge` with
To use the bridge, you need to start a chat with `Slack Puppet Bridge` with the handle `@_slackpuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
the handle `@_slackpuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
Three authentication methods are available, Legacy Token, OAuth and xoxc token.
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-slack [documentation](https://gitlab.com/mx-puppet/slack/mx-puppet-slack) for more information about how to configure the bridge.
See mx-puppet-slack [documentation](https://github.com/Sorunome/mx-puppet-slack)
for more information about how to configure the bridge.
Once logged in, send `list` to the bot user to list the available rooms.
Once logged in, send `list` to the bot user to list the available rooms.
Clicking rooms in the list will result in you receiving an invitation to the
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
bridged room.
Also send `help` to the bot to see the commands available.
Send `help` to the bot to see the available commands.
[mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) for you.
-->
See the project page to learn what it does and why it might be useful to you.
# Setting up MX Puppet Steam bridging (optional)
To enable the [Steam](https://steampowered.com/) bridge just use the following
The playbook can install and configure [mx-puppet-steam](https://github.com/icewind1991/mx-puppet-steam) for you.
playbook configuration:
See the project's [documentation](https://github.com/icewind1991/mx-puppet-steam/blob/master/README.md) to learn what it does and why it might be useful to you.
## Adjusting the playbook configuration
To enable the [Steam](https://steampowered.com/) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
```yaml
```yaml
matrix_mx_puppet_steam_enabled:true
matrix_mx_puppet_steam_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 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
## Usage
Once the bot is enabled you need to start a chat with `Steam Puppet Bridge` with
To use the bridge, you need to start a chat with `Steam Puppet Bridge` with the handle `@_steampuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
the handle `@_steampuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
Three authentication methods are available, Legacy Token, OAuth and xoxc token.
Three authentication methods are available, Legacy Token, OAuth and xoxc token. See mx-puppet-steam [documentation](https://github.com/icewind1991/mx-puppet-steam) for more information about how to configure the bridge.
See mx-puppet-steam [documentation](https://github.com/icewind1991/mx-puppet-steam)
for more information about how to configure the bridge.
Once logged in, send `list` to the bot user to list the available rooms.
Once logged in, send `list` to the bot user to list the available rooms.
Clicking rooms in the list will result in you receiving an invitation to the
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
bridged room.
Also send `help` to the bot to see the commands available.
Send `help` to the bot to see the available commands.
# 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.
**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.
The playbook can install and configure
The playbook can install and configure [mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter) for you.
[mx-puppet-twitter](https://github.com/Sorunome/mx-puppet-twitter) for you.
See the project page to learn what it does and why it might be useful to you.
See the project's [documentation](https://github.com/Sorunome/mx-puppet-twitter/blob/master/README.md) to learn what it does and why it might be useful to you.
To enable the [Twitter](https://twitter.com) bridge, make an app on [developer.twitter.com](https://developer.twitter.com/en/apps)
## Prerequisite
and fill out the following playbook configuration.
Make an app on [developer.twitter.com](https://developer.twitter.com/en/apps).
## Adjusting the playbook configuration
To enable the [Twitter](https://twitter.com) bridge, add the following configuration to your `inventory/host_vars/matrix.example.com/vars.yml` file:
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
## Usage
Once the bot is enabled you need to start a chat with `Twitter Puppet Bridge` with
To use the bridge, you need to start a chat with `Twitter Puppet Bridge` with the handle `@_twitterpuppet_bot:example.com` (where `example.com` is your base domain, not the `matrix.` domain).
the handle `@_twitterpuppet_bot:YOUR_DOMAIN` (where `YOUR_DOMAIN` is your base
domain, not the `matrix.` domain).
To log in, use `link` and click the link.
To log in, use `link` and click the link.
Once logged in, send `list` to the bot user to list the available rooms.
Once logged in, send `list` to the bot user to list the available rooms.
Clicking rooms in the list will result in you receiving an invitation to the
Clicking rooms in the list will result in you receiving an invitation to the bridged room.
bridged room.
Also send `help` to the bot to see the commands available.
Send `help` to the bot to see the available commands.
The playbook can install and configure [Postmoogle](https://github.com/etkecc/postmoogle) for you.
Postmoogle is a bridge you can use to have its bot user forward emails to Matrix rooms. It runs an SMTP email server and allows you to assign mailbox addresses to the rooms.
See the project's [documentation](https://github.com/etkecc/postmoogle/blob/master/README.md) to learn what it does and why it might be useful to you.
## Prerequisites
Open the following ports on your server to be able to receive incoming emails:
-`25/tcp`: SMTP
-`587/tcp`: Submission (TLS-encrypted SMTP)
If you don't open these ports, you will still be able to send emails, but not receive any.
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 |
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
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 a user account of the bridge's bot.
- The shortcut commands with the [`just` program](just.md) are also available: `just install-all` or `just setup-all`
`just install-all` is useful for maintaining your setup quickly ([2x-5x faster](../CHANGELOG.md#2x-5x-performance-improvements-in-playbook-runtime) than `just setup-all`) when its components remain unchanged. If you adjust your `vars.yml` to remove other components, you'd need to run `just setup-all`, or these components will still remain installed.
- If you change the bridge's bot password (`matrix_postmoogle_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_postmoogle_password` to let the bot know its new password.
## Usage
To use the bridge, invite the `@postmoogle:example.com` bot user into a room you want to use as a mailbox.
Then send `!pm mailbox NAME` to expose this Matrix room as an inbox with the email address `NAME@matrix.example.com`. Emails sent to that email address will be forwarded to the room.
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).
## 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-postmoogle`.
### 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 [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:
```yaml
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 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 `@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.
Cactus Comments is a **federated comment system** built on Matrix. It respects your privacy, and puts you in control.
See the project's [documentation](https://cactus.chat/docs/getting-started/introduction/) to learn what it does and why it might be useful to you.
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-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).
## 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
# 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
```
### 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 `vars.yml` file:
```yaml
# Change the default hostname and path prefix to host the client assets at a different location
# These variables are used only if (`matrix_cactus_comments_client_enabled: true`)
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`.
When setting, replace `example.com` with your own.
### Extending the 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
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.
## Usage
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).
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!
## Embed Cactus Comments
The official [documentation](https://cactus.chat/docs/getting-started/quick-start/) provides a useful guide to embed Cactus Comments on your website.
After including the JavaScript and CSS asset files, insert a `<div>` where you'd like to display the comment section:
````html
<div id="comment-section"></div>
````
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:
To have the assets served from your homeserver (not from `cactus.chat`), you need to adjust the domain name on the official documentation.
Make sure to replace `example.com` with your base domain before you include the following lines, instead of the one provided by the official documentation:
**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.
SPDX-License-Identifier: AGPL-3.0-or-later
cinny is a web client focusing primarily on simple, elegant and secure interface.
-->
cinny can be installed alongside or instead of Element.
If you'd like cinny to be installed, add the following to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
# Setting up Cinny (optional)
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).
💡 **Note**: the latest version of Cinny 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:
- [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:
```yaml
```yaml
matrix_client_cinny_enabled:true
matrix_client_cinny_enabled:true
```
```
You will also need to add a DNS record so that cinny can be accessed.
### Adjusting the Cinny URL (optional)
By default cinny will use https://cinny.DOMAIN so you will need to create an CNAME record
for `cinny`. See [Configuring DNS](configuring-dns.md).
If you would like to use a different domain, add the following to your configuration file (changing it to use your preferred domain):
By tweaking the `matrix_client_cinny_hostname` variable, you can easily make the service available at a **different hostname** than the default one.
Example additional configuration for your `vars.yml` file:
```yaml
```yaml
matrix_server_fqn_cinny:"app.{{ matrix_domain }}"
# 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.
**Note**: while there is a `matrix_client_cinny_path_prefix` variable for changing the path where Cinny is served, overriding it is [not possible](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/3701), because Cinny requires an application rebuild (with a tweaked build config) to be functional under a custom path. You'd need to serve Cinny at a dedicated subdomain.
### Extending the configuration
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
## Installing
After configuring the playbook and [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-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/)
## Adjusting DNS records
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`.
When setting, replace `example.com` with your own.
## Adjusting the playbook configuration
### Set the country code for phone number inputs
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:
```yaml
matrix_client_element_default_country_code:"FR"
```
### Themes
#### Change the default theme
You can change the default theme from `light` to `dark`. To do so, add the following configuration to your `vars.yml` file:
```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.
#### Define themes manually
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 `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 Element Web.
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:
<!-- 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-element`.
By default, this playbook installs the [Element](https://github.com/vector-im/element-web) Matrix client web application.
If that's okay, you can skip this document.
## Disabling Element
If you'd like for the playbook to not install Element (or to uninstall it if it was previously installed), you can disable it in your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
```yaml
matrix_client_element_enabled:false
```
## Configuring Element settings
The playbook provides some customization variables you could use to change Element's settings.
Their defaults are defined in [`roles/matrix-client-element/defaults/main.yml`](../roles/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/matrix-client-element/templates/config.json.j2`](../roles/matrix-client-element/templates/config.json.j2) template.
**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.<your-domain>/vars.yml`) and [re-run the playbook](installing.md) to apply the changes.
Alternatively, **if there is no pre-defined variable** for an Element 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's various settings that rarely get used.
- or, you can **extend and override the default configuration** ([`config.json.j2`](../roles/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/matrix-client-element/defaults/main.yml`](../roles/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/matrix-client-element/defaults/main.yml`](../roles/matrix-client-element/defaults/main.yml).
## Themes
To change the look of Element, you can define your own themes manually by using the `matrix_client_element__settingDefaults_custom_themes` setting.
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`).
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.
Note that for a custom theme to work well, all Element instances that you use must have the same theme installed.
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/vector-im/hydrogen-web) Matrix web client for you.
SPDX-License-Identifier: AGPL-3.0-or-later
Hydrogen is a lightweight web client that supports mobile and legacy web browsers.
-->
Hydrogen can be installed alongside or instead of Element.
If you'd like Hydrogen to be installed, add the following to your configuration file (`inventory/host_vars/matrix.<your-domain>/vars.yml`):
# Setting up Hydrogen (optional)
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:
```yaml
```yaml
matrix_client_hydrogen_enabled:true
matrix_client_hydrogen_enabled:true
```
```
You will also need to add a DNS record so that Hydrogen can be accessed.
### Adjusting the Hydrogen URL (optional)
By default Hydrogen will use https://hydrogen.DOMAIN so you will need to create an CNAME record
for `hydrogen`. See [Configuring DNS](configuring-dns.md).
If you would like to use a different domain, add the following to your configuration file (changing it to use your preferred domain):
By tweaking the `matrix_client_hydrogen_hostname` and `matrix_client_hydrogen_path_prefix` variables, you can easily make the service available at a **different hostname and/or path** than the default one.
Example additional configuration for your `vars.yml` file:
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:
<!-- 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-hydrogen`.
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.
💡 **Note**: the latest version of SchildiChat 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:
- [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:
```yaml
matrix_client_schildichat_enabled:true
```
### Set the country code for phone number inputs
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:
You can change the default theme from `light` to `dark`. To do so, add the following configuration to your `vars.yml` file:
```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.
#### Define themes manually
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 `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 SchildiChat Web.
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:
<!-- 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-schildichat`.
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.