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.
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 fdd37f0247
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 21:05:53 2024 +0300
Add documentation for WeChat bridge
commit 8426fc8b95
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 da200df82b
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 4022cb1355
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 d07a39b4c4
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 ccca72f8d1
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 20:49:06 2024 +0300
Move WeChat agent configuration to a template
commit a4047d94d8
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 bc0e89f345
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 a46f5b9cbc
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 19:48:17 2024 +0300
Rename some files
commit 3877679040
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 e3e95ab234
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 4d5748ae9b
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:57:09 2024 +0300
Pin wechat and wechat-agent versions
commit 40d40009f1
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:53:58 2024 +0300
docker_image -> container_image for WeChat bridge
commit cc33aff592
Author: Slavi Pantaleev <slavi@devture.com>
Date: Mon Jun 3 18:00:25 2024 +0300
docker_src -> container_src in WeChat bridge
commit 42e6ae9a64
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 d6662a69d1
Author: Tobias Diez <code@tobiasdiez.de>
Date: Mon Mar 25 10:55:16 2024 +0800
Add wechat bridge
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>
* 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>
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`
* 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
* 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>
Slavi Pantaleev
Kuchenmampfer
Fabio Bonelli
HarHarLinks
Kim Brose
ash
Marty
Johan Swetzén
Catalan Lover
gardar
Catalan Lover
Suguru Hirahara
throny
xvsun
Benjamin Kampmann
Tupsi
Array in a Matrix
Antoine-Ali Zarrouk
needo37
Ingy döt Net
Ed Geraghty
Wave
Jost Alemann
darksnakezero
SirHazza