2020-03-18 Selfhosting Jitsi

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

Image 1

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...

Tags:

Comments

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.tld
  • conference.jitsi.domain.tld
  • jitsi-videobridge.jitsi.domain.tld
  • focus.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


Please make sure you contribute only your own work, or work licensed under the GNU Free Documentation License. Note: in order to facilitate peer review and fight vandalism, we will store your IP number for a number of days. See Privacy Policy for more information. See Info for text formatting rules. You can edit the comment page if you need to fix typos. You can subscribe to new comments by email without leaving a comment.

To save this page you must answer this question:

Just say HELLO