This removes an unused letsencrypt dir bind mount for jitsi-meet web
that was causing confusion (we run letsencrypt out of band and put the
certs in the correct dir so we don't need this specific bind mount).
We also remove the now unused config.js config file from the role.
We stop managing the default nginx config and instead rely on the
container provided template. To properly configure http redirects we
set the ENABLE_HTTP_REDIRECT flag in the env var file.
Finally we update the README file with a bit more info on how this all
works.
Change-Id: Iecb68c9855b5627d25f8bb586b0e6f366f1c80ab
This restores useRoomAsSharedDocumentName and openSharedDocumentOnJoin
config settings in our jitsi meet config.js. We had lost these settings
in the recent jitsi meet web container update. To restore them we
provide an alternative settings-config.js template to the container so
that when it generates its configs we get these vars included.
We stop managing the config.js file in /var/jitsi-meet/web to avoid
confusion with ansible replacing configs that may be used then.
Change-Id: I4d2bd77e03812695792cda2abb7f401288186f2c
This starts conferences with participant video muted and it disabled p2p
connections for calls between two participants. We had these settings
before but the recent container image update undid them.
Change-Id: I4152ace083f79116758020fbbcbbb96e39eef9ed
The jitsi meet containers want to generate configuration from the
templates found in /defaults on the container to config files in the
bind mounted /config (/var/jitsi-meet/ on the host side). This means
that the configs ansible is writing to /var/jitsi-meet are complete
ignored and overwritten by the container using its templating system and
env vars.
This is causing us problems because we would like to use a different
etherpad prxoy config in nginx to ensure the Host header is set
properly. To make this happen we bind mount in our own template file so
that the container can template what we want rather than what is found
in the image.
Change-Id: Ifdde66a01bb7e632fc19ca0a512216584f1ea9f0
We unforked our jitsi web container and discovered that etherpad doc
embedding was broken. In the process of debugging this the jitsi meet
services on meetpad were restart which pulled in newer configs which
expect ENABLE_XMPP_WEBSOCKET to be enabled by default. Unfortunately
this wasn't quite working for us. Explicitly disabling this seems to
make audio and video calling work again. But doc sharing isn't even
attempted now.
Let's get this fix in as audio and video are important then we'll keep
debugging the etherpad doc sharing problem.
https://github.com/jitsi/docker-jitsi-meet/issues/902 has details from
others that hit this problem.
Note that part of the issue here seems to be that nginx is using the
default configs in the container found at /default and not the configs
we bind mount at /config. This at least seems to be why the proxying for
etherpad documents is broken.
Change-Id: I03fa9d331e6825b3b953a3573c0dd43c7be478a4
This has our change to open etherpad on join, so we should no longer need
to run a fork of the web server. Switch to the upstream container image
and stop building our own.
Change-Id: I3e8da211c78b6486a3dcbd362ae7eb03cc9f5a48
For privacy reasons, it is better to start with video muted, as some
browsers might remember a previous authorization.
Change-Id: Ie2ed987236a4b0627f968dc5e2fb92e0a77a794a
Remove firefox from the "optimal browsers" list so that when someone
joins with ff, they get a message indicating that another browser is
recommended. They can still join.
Also disable background blurring, since that currently seems to be
producing a poor experience when used.
Change-Id: Ie161fef6351337c4e1102d1ab645367a71e5b4bf
The jitsi video bridge (jvb) appears to be the main component we'll need
to scale up to handle more users on meetpad. Start preliminary
ansiblification of scale out jvb hosts.
Note this requires each new jvb to run on a separate host as the jvb
docker images seem to rely on $HOSTNAME to uniquely identify each jvb.
Change-Id: If6d055b6ec163d4a9d912bee9a9912f5a7b58125
Disable the jitsi logo watermark which is displayed in the top left
portion of the jitsi conference toolbar. The reason for this is it seems
to cause rendering issues with the etherpads that are loaded in meetpad.
Even without the rendering issues it covers the beginning portion of
etherpads which is annoying.
To do this we copy over the interface config and edit the two variables
related to displaying the watermark. All other values are kept
consistent with the defaults in the docker image.
Change-Id: I1e363d780083894fc53a030349fbc36567891271
If we match these explicit paths, don't allow the regex matches to
run. Otherwise, we might redirect "/http-bind" to "/" which doesn't
work.
Also, restore the default meet.conf to the upstream; we're not
intending to carry any local changes to the rootfs.
Change-Id: I119d8c223291d79bd5fe0977264dec4bae126280
Many people put hyphens (-) and underscores (_) in their pad names,
and Jitsi-Meet seems to support them in its room names too, so add
them to our rewrite regex.
Change-Id: I819b8d56bf839cf743319e9cd823440c7d910001
This makes two changes: it proxies all etherpad traffic through
the nginx running in docker in order to avoid any weird cross-domain
problems.
It also switches to using the new etherpad.opendev.org server.
Change-Id: I99f7f284088f0d241a8490d01cccdf782bdd45d2
The new opendev etherpad is up and running. While not in production yet
(we need to transition the DB from etherpad.openstack.org) it should be
fine to have meetpad start using it now as meetpad isn't in production
either.
Change-Id: Ic1917688cba37c03e45e3bccbce6fc723022b94c
This is to test if newer etherpad-lite works with jitsi integration
better.
Note that etherpad-dev uses a self signed ssl cert. When testing this
you may have to navigate to https://etherpad-dev.openstack.org and
permanently accept the ssl cert there before using meetpad. Then when
testing is done you can go back and remove the exception to ssl
verification.
Change-Id: Ie5a3db3f3ab762445afff6281cb372f90afc1410
This config file was auto-generated from an earlier attempt and
mistakenly used 'localhost.localdomain' rather than just 'localhost'.
Change-Id: I761fe24e50e299f78f9ee1b07aefb527c8b2ed44
