This also reverts e5574a405e43a51ab152e0e4cf760a3cc021adbe 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>
