titanz
/
matrix-docker-ansible-deploy
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '179b416ed5'
${ noResults }
matrix-docker-ansible-deploy/roles/matrix-jitsi/templates/web/env.j2

43 lines
1.7 KiB
Raw Normal View History Unescape

Add Jitsi support
5 years ago
ENABLE_AUTH={{ 1 if matrix_jitsi_enable_auth else 0 }}
ENABLE_GUESTS={{ 1 if matrix_jitsi_enable_guests else 0 }}
ENABLE_TRANSCRIPTIONS={{ 1 if matrix_jitsi_enable_transcriptions else 0 }}
Update Jitsi to build 5142 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.
4 years ago
ENABLE_P2P={{ 1 if matrix_jitsi_enable_p2p else 0 }}
Add Jitsi support
5 years ago
DISABLE_HTTPS=1
JICOFO_AUTH_USER={{ matrix_jitsi_jicofo_auth_user }}
PUBLIC_URL={{ matrix_jitsi_web_public_url }}
XMPP_DOMAIN={{ matrix_jitsi_xmpp_domain }}
XMPP_AUTH_DOMAIN={{ matrix_jitsi_xmpp_auth_domain }}
XMPP_BOSH_URL_BASE={{ matrix_jitsi_xmpp_bosh_url_base }}
XMPP_GUEST_DOMAIN={{ matrix_jitsi_xmpp_guest_domain }}
XMPP_MUC_DOMAIN={{ matrix_jitsi_xmpp_muc_domain }}
XMPP_RECORDER_DOMAIN={{ matrix_jitsi_recorder_domain }}
TZ={{ matrix_jitsi_timezone }}
JIBRI_BREWERY_MUC={{ matrix_jitsi_jibri_brewery_muc }}
JIBRI_PENDING_TIMEOUT={{ matrix_jitsi_jibri_pending_timeout }}
JIBRI_XMPP_USER={{ matrix_jitsi_jibri_xmpp_user }}
JIBRI_XMPP_PASSWORD={{ matrix_jitsi_jibri_xmpp_password }}
JIBRI_RECORDER_USER={{ matrix_jitsi_jibri_recorder_user }}
JIBRI_RECORDER_PASSWORD={{ matrix_jitsi_jibri_recorder_password }}
ENABLE_RECORDING={{ 1 if matrix_jitsi_enable_recording else 0 }}
Update Jitsi to build 5142 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.
4 years ago
RESOLUTION={{ matrix_jitsi_web_config_resolution_height_ideal_and_max }}
RESOLUTION_MIN={{ matrix_jitsi_web_config_resolution_height_min }}
RESOLUTION_WIDTH={{ matrix_jitsi_web_config_resolution_width_ideal_and_max }}
RESOLUTION_WIDTH_MIN={{ matrix_jitsi_web_config_resolution_width_min }}
START_AUDIO_MUTED={{ matrix_jitsi_web_config_start_audio_muted_after_nth_participant }}
START_VIDEO_MUTED={{ matrix_jitsi_web_config_start_video_muted_after_nth_participant }}
Etherpad Jitsi integration
4 years ago
ETHERPAD_URL_BASE={{ (matrix_jitsi_etherpad_base + '/') if matrix_jitsi_etherpad_enabled else ''}}
Update Jitsi to build 5142 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.
4 years ago
{{ matrix_jitsi_web_environment_variables_extension }}