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>
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).
* 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 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>
* 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>
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 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
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>
