As of docker-jitsi-meet stable-6433 [1], `/config/interface_config.js`
is regenerated on every boot. The correct way to modify the interface
config is now via `/config/custom-interface_config.js`, which is
appended to a default copy of `interface_config.js` by
`/etc/cont-init.d/10-config` on every boot of the docker image.
Given that `interface_config.js` is considered deprecated by upstream
(all options will eventually be moved to `config.js`), we also deprecate
the `matrix_jitsi_web_interface_config_*` variables in favour of
`matrix_jitsi_web_custom_interface_config_extension`.
[1] https://github.com/jitsi/docker-jitsi-meet/blob/stable-6433/CHANGELOG.md#stable-6433
It's not like it worked anyway, because we don't have the necessary
services installed for transcription (Jigasi), nor recording (Jibri).
Disabling these, should hopefully disable their related elements
in the Jitsi Web UI.
Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/726
This supersedes/fixes-up this Pull Request:
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/719
The Jitsi Web and JVB containers now (in build 5142) always
start by bulding their own default configuration
(`config.js` and `sip-communicator.properties`, respectively).
The fact that we were generating these files ourselves was no longer of use,
because our configuration was thrown away in favor of the one created
by the containers on startup.
With this commit, we're completely redoing things. We no longer
generate these configuration files. We try to pass the proper
environment variables, so that Jitsi services can generate the
configuration files themselves.
Besides that, we try to use the "custom configuration" mechanism
provided by Jitsi Web and Jitsi JVB (`custom-config.js` and
`custom-sip-communicator.properties`, respectively), so that
we and our users can inject additional configuration.
Some configuration options we had are gone now. Others are no longer
controllable via variables and need to be injected using
the `_config_extension` variables that we provide.
The validation logic that is part of the role should take care
to inform people about how to upgrade (if they're using some custom
configuration, which needs special care now). Most users should not
have to do anything special though.
Hopefully fixes an error like this (which I haven't been able to
reproduce, but..):
> [modules/xmpp/strophe.util.js] <Object.i.Strophe.log>: Strophe: Error: Failed to construct 'RTCPeerConnection': 'matrix.DOMAIN' is not one of the supported URL schemes 'stun', 'turn' or 'turns'.
We do this for 2 reasons:
- so we can control things which are not controllable using environment
variables (for example `stunServers` in jitsi/web, since we don't wish
to use the hardcoded Google STUN servers if our own Coturn is enabled)
- so playbook variable changes will properly rebuild the configuration.
When using Jitsi environment variables, the configuration is only built
once (the first time) and never rebuilt again. This is not the
consistent with the rest of the playbook and with how Ansible operates.
We're not perfect at it (yet), because we still let the Jitsi containers
generate some files on their own, but we are closer and it should be
good enough for most things.
Related to #415 (Github Pull Request).
GoliathLabs
Chris van Dijk
sakkiii
ppacheco28
sak
SkepticalWaves
ewang
Eagle-251
Béla Becker
Ahmad Haghighi
Slavi Pantaleev
rakshazi
João Marques
Tommy Kelly
teutat3s
Pablo
Alin Trăistaru