I’m trying to self-host Jitsi (”multi-platform open-source video conferencing”).
1. follow the instructions and use their Ubuntu/Debian repository
2. I already have the subdomain `chat.campaignwiki.org` setup with *Gandi*
3. add `chat.campaignwiki.org` to the existing Campaign Wiki domain names in `/etc/dehydrated/domains.txt` such that *Let’s Encrypt* will pick it up
4. edit the Apache config file they generate and comment their settings for `SSLProtocol`, `SSLCipherSuite` and `SSLHonorCipherOrder`, preferring my own
5. enable the site using `a2ensite` and restart Apache gracefully using `systemctl reload apache2`
Testing:
1. chat.campaignwiki.org seems to work!
2. got to Firefox preferences and search for Microphone and Camera and make sure to allow requests asking to access them (which I have disabled by default)
3. on the phone, install the `Jitsi Meet` app (not sure why the browser isn’t good enough on the phone?)
4. use the test room to test it...
I get the rooms listed, but I am immediately disconnected when accessing it on the phone. Not good!
I also get disconnected every now and then when using the website on my laptop. Hm.
OK, opening two private browsing windows and connecting to a channel on the official site seems to work. At least I get two copies of my camera showing video and I can chat with myself. It also works with the app on the phone. Thus, this is not an app or browser problem.
Back to my own installation. Let’s check the logs at `/var/log/jitsi/jicofo.log`. Some things to note after a restart:
1. “Lonely participants will be “terminated” after 20000 milliseconds” → that would explain my automatic disconnects on the laptop after a bit
2. the XMPP component says “This server does not serve auth.campaignwiki.org” but I think that’s OK?
3. I also see references to jitsi-videobridge.campaignwiki.org and focus.campaignwiki.org but surely this cannot work?
4. there are other Java exceptions, too; these look concerning: “ClassNotFoundException: javax.activation.DataSource”, “ClassNotFoundException: javax.xml.bind.PropertyException”, and “ClassNotFoundException: javax.xml.bind.Unmarshaller”
I think I need to redo my setup. Perhaps the domain name setup was a problem? I remember providing the wrong domain name at some point and then just fixing it in the Apache site config.
1. `apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-web jicofo jitsi-videobridge`
2. `apt install -y jitsi-meet`
3. domain to use: `chat.campaignwiki.org`
4. use my own certificates: `/var/lib/dehydrated/certs/campaignwiki.org/privkey.pem` and `/var/lib/dehydrated/certs/campaignwiki.org/cert.pem`
The differences in the Apache site setup:
--- /etc/apache2/sites-available/chat.campaignwiki.org.conf +++ /etc/apache2/sites-available/600-chat.campaignwiki.org.conf @@ -11,13 +11,14 @@ ServerName chat.campaignwiki.org - SSLProtocol TLSv1 TLSv1.1 TLSv1.2 + # SSLProtocol TLSv1 TLSv1.1 TLSv1.2 SSLEngine on SSLProxyEngine on - SSLCertificateFile /var/lib/dehydrated/certs/campaignwiki.org/cert.pem - SSLCertificateKeyFile /var/lib/dehydrated/certs/campaignwiki.org/privkey.pem - SSLCipherSuite "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED" - SSLHonorCipherOrder on + SSLCertificateFile /var/lib/dehydrated/certs/campaignwiki.org/cert.pem + SSLCertificateKeyFile /var/lib/dehydrated/certs/campaignwiki.org/privkey.pem + SSLCertificateChainFile /var/lib/dehydrated/certs/campaignwiki.org/chain.pem + # SSLCipherSuite "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED" + # SSLHonorCipherOrder on Header set Strict-Transport-Security "max-age=31536000" DocumentRoot "/usr/share/jitsi-meet" Diff finished. Wed Mar 18 10:33:44 2020
I still get the same problem:
1. `https://chat.campaignwiki.org/Test` loads
2. I see the UI
3. I am reconnected after a few seconds
Trying to see whether the hostnames make more sense, now:
# grep campaignwiki /etc/prosody/conf.d/chat.campaignwiki.org.cfg.lua
VirtualHost "chat.campaignwiki.org"
key = "/etc/prosody/certs/chat.campaignwiki.org.key";
certificate = "/etc/prosody/certs/chat.campaignwiki.org.crt";
Component "conference.chat.campaignwiki.org" "muc"
admins = { "focus@auth.chat.campaignwiki.org" }
Component "jitsi-videobridge.chat.campaignwiki.org"
VirtualHost "auth.chat.campaignwiki.org"
key = "/etc/prosody/certs/auth.chat.campaignwiki.org.key";
certificate = "/etc/prosody/certs/auth.chat.campaignwiki.org.crt";
Component "focus.chat.campaignwiki.org"
These subdomains make my head hurt. How can this work? I have added the four of them to my `/etc/hosts` file, but no effect. Not surprisingly, it turns out that these need to be “real” domains, reachable from the outside. Continue reading the comments...
#Administration #Jitsi
(Please contact me if you want to remove your comment.)
⁂
What domain do you have in `/etc/jitsi/meet/*-config.js` ? Search the wrong domain with `ack --js /etc` or something. Frankly, it might be faster to redo the install from scratch on a new machine: it shouldn’t take more than 5-10 min, if you have all the ports open and there’s no other webserver installed on the same machine.
– Federico 2020-03-18 11:02 UTC
---
I have already redone the config once, so I don’t mind doing it again, but I need to understand what went wrong because the problem seems to be unchanged.
I checked the config file:
# grep campaignwiki /etc/jitsi/meet/chat.campaignwiki.org-config.js
domain: 'campaignwiki.org',
// authdomain: 'campaignwiki.org',
// jirecon: 'jirecon.campaignwiki.org',
// call_control: 'callcontrol.campaignwiki.org',
// focus: 'focus.campaignwiki.org',
muc: 'conference.campaignwiki.org'
bosh: '//campaignwiki.org/http-bind',
// focusUserJid: 'focus@auth.campaignwiki.org',
// // 'https://campaignwiki.org/static/oauth.html'
// 'https://campaignwiki.org/subfolder/static/oauth.html'
This is strange, because the “chat” subdomain seems to be missing. I’ll add that and try again:
--- /etc/jitsi/meet/chat.campaignwiki.org-config.js~
+++ /etc/jitsi/meet/chat.campaignwiki.org-config.js
@@ -6,7 +6,7 @@
hosts: {
// XMPP domain.
- domain: 'campaignwiki.org',
+ domain: 'chat.campaignwiki.org',
// When using authentication, domain for guest users.
// anonymousdomain: 'guest.example.com',
@@ -28,7 +28,7 @@
},
// BOSH URL. FIXME: use XEP-0156 to discover it.
- bosh: '//campaignwiki.org/http-bind',
+ bosh: '//chat.campaignwiki.org/http-bind',
// The name of client node advertised in XEP-0115 'c' stanza
clientNode: 'http://jitsi.org/jitsimeet',
Diff finished. Wed Mar 18 12:26:23 2020
Sadly, that doesn’t work either. Now I’m getting an “Unfortunately, something went wrong” error.
– Alex Schroeder 2020-03-18 11:20 UTC
---
OK, next attempt. I found this in the Juno Host docs:
Jitsi requires you create additionals domains in your DNS and in your YunoHost
auth.jitsi.domain.tldconference.jitsi.domain.tldjitsi-videobridge.jitsi.domain.tldfocus.jitsi.domain.tld
So I created them:
chat 10800 IN A 178.209.50.237 chat 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 chat.auth 10800 IN A 178.209.50.237 chat.auth 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 chat.conference 10800 IN A 178.209.50.237 chat.conference 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 chat.focus 10800 IN A 178.209.50.237 chat.focus 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 chat.jitsi-videobridge 10800 IN A 178.209.50.237 chat.jitsi-videobridge 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1
And the config file:
--- /etc/jitsi/meet/chat.campaignwiki.org-config.js~
+++ /etc/jitsi/meet/chat.campaignwiki.org-config.js
@@ -6,7 +6,7 @@
hosts: {
// XMPP domain.
- domain: 'campaignwiki.org',
+ domain: 'chat.campaignwiki.org',
// When using authentication, domain for guest users.
// anonymousdomain: 'guest.example.com',
@@ -24,11 +24,11 @@
// focus: 'focus.campaignwiki.org',
// XMPP MUC domain. FIXME: use XEP-0030 to discover it.
- muc: 'conference.campaignwiki.org'
+ muc: 'conference.chat.campaignwiki.org'
},
// BOSH URL. FIXME: use XEP-0156 to discover it.
- bosh: '//campaignwiki.org/http-bind',
+ bosh: '//chat.campaignwiki.org/http-bind',
// The name of client node advertised in XEP-0115 'c' stanza
clientNode: 'http://jitsi.org/jitsimeet',
Diff finished. Wed Mar 18 21:12:06 2020
And now a single user can connect! I can connect to a chatroom and I see my video. No constant reconnects. I also had to restart Prosody with `service prosody reload`.
The only problem now is that whenever I connect to the same chatroom from a different private window or the phone, both sessions are terminated.
Perhaps this is still related to certificates? I think the one I have is only good for campaignwiki.org, www.campaignwiki.org, and chat.campaignwiki.org – but I need more subdomains, apparently.
– Alex Schroeder 2020-03-18 20:21 UTC
---
I decided to use the `prosody cert` calls mentioned in the Configure Prosody section. (Now I remember how I failed to set it up a while ago.)
Anyway:
prosodyctl cert generate chat.campaignwiki.org prosodyctl cert generate auth.chat.campaignwiki.org systemctl restart prosody
OK... I can now connect with both browser and phone, and we see each other in the channel, but both believe the other is muted and has no video!
Gaaaah.
– Alex Schroeder 2020-03-18 20:32 UTC
---
OK, `/var/log/jitsi/jicofo.log` has a SEVERE message: “... XMPP reconnection failed: ... SSLHandshakeException: PKIX path validation failed: ... CertPathValidatorException: signature check failed”
Let’s try this:
ln -sf /var/lib/prosody/auth.chat.campaignwiki.org.crt /usr/local/share/ca-certificates/ update-ca-certificates -f systemctl restart prosody systemctl restart jicofo systemctl restart jitsi-videobridge
– Alex Schroeder 2020-03-18 20:48 UTC
---
Oh wow, it works! 😀
– Alex Schroeder 2020-03-18 20:50 UTC
---
If you’re using the app on your phone, note the trackers!
– Alex Schroeder 2020-03-18 21:21 UTC
---
Oh, cool:
– Alex Schroeder 2020-03-19 11:51 UTC
---
Some stuff is still not correct. Jitsi should give me a working XMPP server, too, as far as I understand it. Right now, however, Bitlbee gives me an error: “Login error: Certificate verification problem 0x14: certificate hasn’t got a known issuer”. That isn’t too surprising, considering that I self-generated certificates and added one of them to the local trust db. I guess the answer is to generate a certificate using Let’s Encrypt for all the domains in question.
I edited `/etc/dehydrated/domains.txt` and now I’m listing these:
campaignwiki.org www.campaignwiki.org chat.campaignwiki.org auth.chat.campaignwiki.org
When I run `dehydrated -c` I get an error:
+ Responding to challenge for auth.chat.campaignwiki.org authorization...
+ Hook: Nothing to do...
+ Cleaning challenge tokens...
+ Hook: Nothing to do...
+ Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "http-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:dns",
"detail": "DNS problem: NXDOMAIN looking up A for auth.chat.campaignwiki.org - check that a DNS record exists for this domain",
"status": 400
},
"url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/3446546602/NNlp-g",
"token": "l7Q3SpNFqQgZT3lnVVEPps0DvN1NkoyfG5rhC_dEMwY"
})
When I run `dig` on `campaignwiki.org`, `www.campaignwiki.org`, `chat.campaignwiki.org` and `auth.chat.campaignwiki.org` I do get some output but it doesn’t look correct:
;; QUESTION SECTION: ;auth.chat.campaignwiki.org. IN A ;; AUTHORITY SECTION: campaignwiki.org. 2776 IN SOA ns1.gandi.net. hostmaster.gandi.net. 1584556785 10800 3600 604800 10800
Compare with the following:
;; QUESTION SECTION: ;chat.campaignwiki.org. IN A ;; ANSWER SECTION: chat.campaignwiki.org. 3216 IN A 178.209.50.237
So the answer section doesn’t include the subdomain. How strange.
Actually...
;; QUESTION SECTION: ;chat.auth.campaignwiki.org. IN A ;; ANSWER SECTION: chat.auth.campaignwiki.org. 3600 IN A 178.209.50.237
I think I got it backwards! 😟
Let’s try the following in my DNS setup:
chat 10800 IN A 178.209.50.237 chat 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 auth.chat 10800 IN A 178.209.50.237 auth.chat 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 conference.chat 10800 IN A 178.209.50.237 conference.chat 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 focus.chat 10800 IN A 178.209.50.237 focus.chat 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1 jitsi-videobridge.chat 10800 IN A 178.209.50.237 jitsi-videobridge.chat 10800 IN AAAA 2a02:418:6a04:178:209:50:237:1
– Alex Schroeder 2020-03-19 12:34 UTC
---
OK, fixing stuff, now that the subdomains and subsubdoains 🙂 are ready:
rm /usr/local/share/ca-certificates/auth.chat.campaignwiki.org.crt
rm /etc/prosody/certs/*campaign*
for subdomain in chat auth.chat focus.chat jitsi-videobridge.chat conference.chat; do
cat /var/lib/dehydrated/certs/campaignwiki.org/fullchain.pem > /etc/prosody/certs/$subdomain.campaignwiki.org.crt
cat /var/lib/dehydrated/certs/campaignwiki.org/privkey.pem > /etc/prosody/certs/$subdomain.campaignwiki.org.key
done
chown prosody.prosody /etc/prosody/certs/*campaign*
update-ca-certificates -f
systemctl restart prosody
systemctl restart jicofo
systemctl restart jitsi-videobridge
So now I’m expecting the following:
# ls -l /etc/prosody/certs total 40 -rw-r--r-- 1 prosody prosody 4006 Mar 19 22:10 auth.chat.campaignwiki.org.crt -rw-r--r-- 1 prosody prosody 3243 Mar 19 22:10 auth.chat.campaignwiki.org.key -rw-r--r-- 1 prosody prosody 4006 Mar 19 22:10 chat.campaignwiki.org.crt -rw-r--r-- 1 prosody prosody 3243 Mar 19 22:10 chat.campaignwiki.org.key -rw-r--r-- 1 prosody prosody 4006 Mar 19 22:10 conference.chat.campaignwiki.org.crt -rw-r--r-- 1 prosody prosody 3243 Mar 19 22:10 conference.chat.campaignwiki.org.key -rw-r--r-- 1 prosody prosody 4006 Mar 19 22:10 focus.chat.campaignwiki.org.crt -rw-r--r-- 1 prosody prosody 3243 Mar 19 22:10 focus.chat.campaignwiki.org.key -rw-r--r-- 1 prosody prosody 4006 Mar 19 22:10 jitsi-videobridge.chat.campaignwiki.org.crt -rw-r--r-- 1 prosody prosody 3243 Mar 19 22:10 jitsi-videobridge.chat.campaignwiki.org.key lrwxrwxrwx 1 root root 37 Jan 9 2019 localhost.crt -> ../../ssl/certs/ssl-cert-snakeoil.pem lrwxrwxrwx 1 root root 39 Jan 9 2019 localhost.key -> ../../ssl/private/ssl-cert-snakeoil.key
As you can see, the various certificates are all identical because I’ve setup `dehydrated` such that the one certificate works for all these names. This differs from the official Let's Encrypt and Prosody documentation!
Once these certificates are in place and have the correct owners, I can edit my `hook.sh` for `dehydrated`:
# cat /var/lib/dehydrated/hook.sh
#!/bin/bash
if [ ${1} == "deploy_cert" ]; then
echo " + Hook: Reloading Apache for ${2}..."
service apache2 reload
if [ ${2} == "campaignwiki.org" ]; then
echo " + Hook: Regenerating prosody's files..."
# 3 is privkey, 4 is cert, 5 is fullchain, 6 is chain, 7 is timestamp
# use cat to preserve permissions and ownership
for subdomain in chat auth.chat focus.chat jitsi-videobridge.chat conference.chat; do
cat ${5} > /etc/prosody/certs/$subdomain.campaignwiki.org.crt
cat ${3} > /etc/prosody/certs/$subdomain.campaignwiki.org.key
done
service prosody reload
fi
if [ ${2} == "alexschroeder.ch" ]; then
echo " + Hook: Regenerating monit's .pem file..."
# 3 is privkey, 4 is cert, 5 is fullchain, 6 is chain, 7 is timestamp
# use cat to preserve permissions and ownership
cat ${5} ${3} > /etc/ssl/localcerts/alexschroeder.ch.all.pem
service monit reload
fi
else
echo " + Hook: Nothing to do..."
fi
Everything still seems to work. 🙂
– Alex Schroeder 2020-03-19 21:19 UTC
---
When I check the XMPP server with Bitlbee, however: “BitlBee does not support any of the offered SASL authentication schemes: ANONYMOUS” 😟
– Alex Schroeder 2020-03-19 21:21 UTC
---
Actually, now that I’ve talked to EionRobb on the #bitlbee channel, I think I understand.
1. I need anonymous access to XMPP for Jitsi to work for anonymous users
2. Internally, they get assigned random ids, but that doesn’t bother them because they access Jitsi via a URL that gives them a chat room and so whoever is there knew the URL and is your “friend” so you trust them and the alias they give themselves
3. But from IRC via Bitlbee or via another XMPP client, that doesn’t make sense: you have an id first, like kensanata@pluspora.com, and then you send messages to other people whose id you trust
So, all of this wasn’t actually necessary! 😭
Not sure what to do now. Would a self-signed certificate for auth.chat.campaignwiki.org be enough?
Gah!
– Alex Schroeder 2020-03-19 21:44 UTC
---
OK, let’s figure out how this works. Prosody has uses this config file for the Jitsi stuff: `/etc/prosody/conf.d/chat.campaignwiki.org.cfg.lua`. From a copy in the global config file `/etc/prosody/prosody.cfg.lua`:
-- Certificates -- Every virtual host and component needs a certificate so that clients and -- servers can securely verify its identity. Prosody will automatically load -- certificates/keys from the directory specified here.
OK, so which ones get listed?
1. virtual server localhost (really?)
2. virtual server chat.campaignwiki.org (with a SSL section pointing to `/etc/prosody/certs`)
3. component conference.chat.campaignwiki.org (no SSL section)
4. component jitsi-videobridge.chat.campaignwiki.org (no SSL section)
5. virtual server auth.chat.campaignwiki.org (with a SSL section pointing to `/etc/prosody/certs`)
6. component focus.chat.campaignwiki.org (no SSL section)
Hm. So I’m guessing only the virtual servers with SSL section actually need them. Instead of modifying the files too much, I will simply remove the unnecessary copies of the certificates and not add any self-signed certs back.
---
And for Monit:
check process prosody with pidfile /var/run/prosody/prosody.pid
start program = "/bin/systemctl start prosody"
stop program = "/bin/systemctl stop prosody"
restart program = "/bin/systemctl restart prosody"
if totalmem > 500 MB for 5 cycles then restart
if 3 restarts within 15 cycles then stop
check process jicofo with pidfile /var/run/jicofo.pid
start program = "/bin/systemctl start jicofo"
stop program = "/bin/systemctl stop jicofo"
restart program = "/bin/systemctl restart jicofo"
if totalmem > 500 MB for 5 cycles then restart
if 3 restarts within 15 cycles then stop
check process jitsi-videobridge with pidfile /var/run/jitsi-videobridge/jitsi-videobridge.pid
start program = "/bin/systemctl start jitsi-videobridge"
stop program = "/bin/systemctl stop jitsi-videobridge"
restart program = "/bin/systemctl restart jitsi-videobridge"
if totalmem > 500 MB for 5 cycles then restart
if 3 restarts within 15 cycles then stop
– Alex Schroeder 2020-03-20 08:18 UTC
---
Had my first virtual tea via Jitsi with my wife in another room and a friend in the neighbourhood. Got to experiment with phone and laptop, camera and external microphone. 🙂
– Alex Schroeder 2020-03-20 15:02 UTC
---
I am trying to get Jitsi Meet to work. I have all the hostnames configured and a Let’s Encrypt cert for all of them, and I got nginx configured to show the web-interface. jitsi-videobridge is running and saying things in its logfile, but jicofo only prints a couple of warnings and then nothing more, which I think is wrong? (It is a Java-program after all). Everybody who connects can see video of themselves, and that others are present, but no video or audio from other participants. Any hints? What does jicofo log in your working setup?
– Adam 2020-03-20 16:30 UTC
---
Ah, I got it working by adding the prosody user with the correct password and noticing that port 5347 is only listened on locally, so I should use localhost in jicofo/config and jitsi-videobridge/config. Thanks for the inspiration!
– Adam 2020-03-20 17:04 UTC
---
Jicofo logs a ton of info messages and no errors: focus request, joining the room, chat room event, granted ownership, member joined, another focus request, another member joining the room, another chat room event, a conference created, a participant added, nothing out of the ordinary. There is one warning “no jingle session yet” immediately followed by an info log message saying a session-accept was received.
Back when the setup was not working, I had Java exceptions in there: java.lang.ClassNotFoundException, IllegalArgumentException, stuff like that.
Check for errors in your Prosody log files, too. `/var/log/prosody/prosody.err` had errors (”Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281”) back when it wasn’t working (this was also visible in `/var/log/prosody/prosody.log`).
– Alex Schroeder 2020-03-20 17:05 UTC
---
Hah! Excellent. 🙂
I only have localhost listed in the Jicofo config file:
# grep HOST /etc/jitsi/*/config /etc/jitsi/jicofo/config:JICOFO_HOST=localhost /etc/jitsi/jicofo/config:JICOFO_HOSTNAME=chat.campaignwiki.org /etc/jitsi/videobridge/config:JVB_HOSTNAME=chat.campaignwiki.org /etc/jitsi/videobridge/config:JVB_HOST=
– Alex Schroeder 2020-03-20 17:06 UTC
---
Thanks!
I have localhost in both *HOST= lines; works.*
I can’t make the Android app work, though - it just immediately says it was disconnected. I can’t see it trying to connect in the webserver nor the prosody log - did you do something special to get that working?
– Adam 2020-03-20 18:39 UTC
---
Ah, the app didn’t work because I used the cert.pem instead of the fullchain.pem as the ssl-certificate in the webserver - now the Android app works as well!
– Adam 2020-03-20 18:58 UTC
---
Perfect. Thanks for posting about your experience!
– Alex Schroeder 2020-03-20 23:29 UTC
---
Let’s see... Changing from “stable” to “unstable” in `/etc/apt/sources.list.d/jitsi-stable.list` and running `apt update` and `apt list --upgradable`:
jicofo/unstable 1.0-534-1 amd64 [upgradable from: 1.0-508-1] jitsi-meet-prosody/unstable 1.0.3905-1 all [upgradable from: 1.0.3729-1] jitsi-meet-web-config/unstable 1.0.3905-1 all [upgradable from: 1.0.3729-1] jitsi-meet-web/unstable 1.0.3905-1 all [upgradable from: 1.0.3729-1] jitsi-meet/unstable 1.0.4304-1 all [upgradable from: 1.0.4101-1] jitsi-videobridge/unstable 1132-1 amd64 [upgradable from: 1126-1]
Unfortunately, however:
The following NEW packages will be installed: coturn jitsi-meet-turnserver libevent-core-2.1-6 libevent-extra-2.1-6 libevent-openssl-2.1-6 libevent-pthreads-2.1-6 libhiredis0.14 libnginx-mod-http-auth-pam libnginx-mod-http-dav-ext libnginx-mod-http-echo libnginx-mod-http-geoip libnginx-mod-http-image-filter libnginx-mod-http-subs-filter libnginx-mod-http-upstream-fair libnginx-mod-http-xslt-filter libnginx-mod-mail libnginx-mod-stream nginx nginx-common nginx-full sqlite3 uuid-runtime The following packages will be upgraded: jicofo jitsi-meet jitsi-meet-prosody jitsi-meet-web jitsi-meet-web-config jitsi-videobridge 6 upgraded, 22 newly installed, 0 to remove and 0 not upgraded.
I don’t really want `nginx` – I’m an Apache person!
– Alex Schroeder 2020-03-23 14:56 UTC
---
Installing Coturn to get rid of Google’s STUN servers.
– Alex Schroeder 2020-03-23 23:48 UTC
---
I think I’m running an anonymous TURN server for now. The things we do for Corona! 😇
apt install coturn
Edit `/etc/default/coturn.conf` and change it to `TURNSERVER_ENABLED=1`. Then `systemctl restart coturn` and `systemctl restart jitsi-videobridge` (I guess?). It’s still working, as far as I can tell.
– Alex Schroeder 2020-03-27 16:13 UTC
---
Also note 2020-03-26 Jitsi and the CPU.
– Alex Schroeder 2020-03-29 10:04 UTC