I’ve just setup an instance of the Jitsi video-conference software for my local LUG. Here is an overview of how to set it up on Debian.
Firstly create a new virtual machine to run it. Jitsi is complex and has lots of inter-dependencies. It’s packages want to help you by dragging in other packages and configuring them. This is great if you have a blank slate to start with, but if you already have one component installed and running then it can break things. It wants to configure the Prosody Jabber server and a web server and my first attempt at an install failed when it tried to reconfigure the running instances of Prosody and Apache.
Here’s the upstream install docs [1]. They cover everything fairly well, but I’ll document the configuration I wanted (basic public server with password required to create a meeting).
Basic Installation
The first thing to do is to get a short DNS name like j.example.com. People will type that every time they connect and will thank you for making it short.
Using Certbot for certificates is best. It seems that you need them for j.example.com and auth.j.example.com.
apt install curl certbot /usr/bin/letsencrypt certonly --standalone -d j.example.com,auth.j.example.com -m you@example.com curl https://download.jitsi.org/jitsi-key.gpg.key | gpg --dearmor > /etc/apt/jitsi-keyring.gpg echo "deb [signed-by=/etc/apt/jitsi-keyring.gpg] https://download.jitsi.org stable/" > /etc/apt/sources.list.d/jitsi-stable.list apt-get update apt-get -y install jitsi-meet
When apt installs jitsi-meet and it’s dependencies you get asked many questions for configuring things. Most of it works well.
If you get the nginx certificate wrong or don’t have the full chain then phone clients will abort connections for no apparent reason, it seems that you need to edit /etc/nginx/sites-enabled/j.example.com.conf to use the following ssl configuration:
ssl_certificate /etc/letsencrypt/live/j.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/j.example.com/privkey.pem;
Then you have to edit /etc/prosody/conf.d/j.example.com.cfg.lua to use the following ssl configuration:
key = "/etc/letsencrypt/live/j.example.com/privkey.pem"; certificate = "/etc/letsencrypt/live/j.example.com/fullchain.pem";
It seems that you need to have an /etc/hosts entry with the public IP address of your server and the names “j.example.com j auth.j.example.com”. Jitsi also appears to use the names “speakerstats.j.example.com conferenceduration.j.example.com lobby.j.example.com conference.j.example.com conference.j.example.com internal.auth.j.example.com” but they aren’t required for a basic setup, I guess you could add them to /etc/hosts to avoid the possibility of strange errors due to it not finding an internal host name. There are optional features of Jitsi which require some of these names, but so far I’ve only used the basic functionality.
Access Control
This section describes how to restrict conference creation to authenticated users.
The secure-domain document [2] shows how to restrict access, but I’ll summarise the basics.
Edit /etc/prosody/conf.avail/j.example.com.cfg.lua and use the following line in the main VirtualHost section:
authentication = "internal_hashed"
Then add the following section:
VirtualHost "guest.j.example.com"
authentication = "anonymous"
c2s_require_encryption = false
modules_enabled = {
"turncredentials";
}
Edit /etc/jitsi/meet/j.example.com-config.js and add the following line:
anonymousdomain: 'guest.j.example.com',
Edit /etc/jitsi/jicofo/sip-communicator.properties and add the following line:
org.jitsi.jicofo.auth.URL=XMPP:j.example.com
Then run commands like the following to create new users who can create rooms:
prosodyctl register admin j.example.com
Then restart most things (Prosody at least, maybe parts of Jitsi too), I rebooted the VM.
Now only the accounts you created on the Prosody server will be able to create new meetings. You should be able to add, delete, and change passwords for users via prosodyctl while it’s running once you have set this up.
Conclusion
Once I gave up on the idea of running Jitsi on the same server as anything else it wasn’t particularly difficult to set up. Some bits were a little fiddly and hopefully this post will be a useful resource for people who have trouble understanding the documentation. Generally it’s not difficult to install if it is the only thing running on a VM.
While they look like hostnames, the auth.$HOSTNAME and such do NOT need to be on the certificate.
Derek: I didn’t test with a certificate that doesn’t have auth.j.example.com as a CN, but there is a Prosody VirtualHost section for auth.j.example.com with ssl defined. It could be that the part of Jitsi which connects isn’t doing certificate hostname checks, but it seems like a good practice to use a valid certificate anyway. Even if it could work now without the extra CN makes it work in future.
Great info Russell – thanks for taking the time – I might have a go…
Aces, Russell! A miscellany of items you might wish to review:
[Hmm, I wish this blog software offered preview mode. Here’s hoping.]
1. It’s an extremely good idea to make sure the FQDN is not merely in DNS but also appended to the localhost line in /etc/aliases, and that you’ve done “hostnamectl set-hostname [FQDN]”
2. Update /etc/systemd/system.conf to have:
DefaultLimitNOFILE=65000
DefaultLimitNPROC=65000
DefaultTasksMax=65000
Implement those changes:
# systemctl daemon-reload
After installing packages including Jitsi Videobridge, check system limits to verify:
# systemctl status jitsi-videobridge2 | grep Tasks
Tasks: 39 (limit: 65000)
# cat /proc/`cat /var/run/jitsi-videobridge/jitsi-videobridge.pid`/limits | grep -e processes -e open
Max processes 65000 65000 processes
Max open files 65000 65000 files
#
3. FYI, after you install Jitsi Project third-party repo’s packages for Debian plus either Apache HTTPd or nginx (I used nginx0, the Jitsi Meet packages provide a very robust post-installation script, /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh, that can be run take care of all conversion work to use Let’s Encrypt, with minimal fuss. Recommended.
4. Don’t forget to edit /etc/jitsi/videobridge/sip-communicator.properties to add two new lines, if behind NAT (as was I):
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=[LOCAL IP]
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=[PUBLIC FACING IP]
and comment out line
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
5. I find it desirable to edit /etc/jitsi/meet/[FQDN]-config.js to set:
startWithAudioMuted: true,
startWithVideoMuted: true,
This is extremely helpful towards conserving both bandwidth and CPU capacity on (especially) the Jitsi Videobridge 2 (“JVB2”) component and (to a degree) client machines, and permits per-room scaling well past the ‘soft’ performance- and WebUI-efficiency-related limit of 36 persons and even the ‘hard’ limit of 75 persons per room. As you and I discussed last night, having a large number of persons per room all running streaming video at each other is almost never useful, anyway. Generally, if you’re worrying about hitting either the soft or hard limit on room capacity and seriously are considering 100+ users in a Jitsi Meet room, it mean you’re trying to solve the wrong problem: You should either have users keep outbound video muted unless/until needed, or be using live-streaming, e.g., to YouTube.
Scaling out to greater numbers of rooms to pretty much arbitrary site sizes can be accomplished by connecting in more JVB2 instances, as required.
6. FYI: Example services restart (SysVInit style):
# /etc/init.d/jitsi-videobridge2 restart
[ ok ] Restarting jitsi-videobridge2 (via systemctl): jitsi-videobridge2.service.
# /etc/init.d/jicofo restart
[ ok ] Restarting jicofo (via systemctl): jicofo.service.
# /etc/init.d/prosody restart
[ ok ] Restarting prosody (via systemctl): prosody.service.
# /etc/init.d/nginx restart
[ ok ] Restarting nginx (via systemctl): nginx.service.
#
7. In my deployment, we needed Zabbix monitoring, which turned out to require the zabbix-agent 5.x package provided by backports, since Debian-stable at this date provides 4.0.4, which is [eye-roll] incompatible.
Create /etc/apt/sources.list.d/buster-backports.list containing
deb http://deb.debian.org/debian buster-backports main
# apt-get update
# apt-get -t buster-backports install zabbix-agent
# dpkg -l | grep zabbix
ii zabbix-agent 1:5.0.1+dfsg-1~bpo10+1 amd64 network monitoring solution - agent
#
In /etc/zabbix create psk.conf containing
[key hash]
Edit /etc/zabbix/zabbix_agentd.conf to have
Server=[FQDN of Zabbix server]
ServerActive=[FQDN of Zabbix server]
Hostname=[FQDN of Jitsi Meet host]
HostMetadata=Linux
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=jitsi-status
TLSPSKFile=/etc/zabbix/psk.conf
Edit /etc/nginx/sites-available to add in the port 80 section:
location = /basic_status {
stub_status;
allow 127.0.0.1;
allow [Zabbix server IP];
deny all;
}
Add in the port 4444 section:
location = /basic_status {
stub_status;
allow 127.0.0.1;
allow [Zabbix server IP];
deny all;
}
systemctl restart nginx.service
systemctl start zabbix-agent.service
systemctl enable zabbix-agent.service
On the matter of Jitsi Meet scaling, an acquaintance asked me:
So meetings with more than perhaps 30 participants are a bad idea?
My reply:
Well, Jitsi Project says that there’s a hard limit of 75 participants per conference (room), set in the software. They are intending to soon
raise that, probably to around 100. 35 is a soft limit, where they say ‘the experience will suffer’. Part of that is that the UI is not optimised for that many simultaneous video participants, and also scaling that large a multiple-video-streams load across multiple servers but still having them be in the same conference is difficult, and they’re still working on how to best handle that. (Scaling to more rooms on the other hand is in the bag, and can be done by adding more Jitsi Video Bridge instances, way up into thousands and thousands of participants.)
Some fine points about that, though:
1. There’s no problem to adding a whole lot of audio-only participants (calling in to a VoIP telephone number) to the conference. That lets you effortlessly scale to 50 or even 100 participants.
This averts most of the problem, since the fundamental reason for both the soft and hard limits us that the intensive -video- demands of cross-connecting so many simultaneous users tend to peg CPU usage on even pretty beefy server machines running Jitsi Video Bridge — but no video for a bunch of additional conference-joiners means no pegging.
2. Another way to finesse the soft limit is to have participants default upon conference entry to video turned off & audio muted. This
was how I set the Jitsi Meet instance run by Exhibits. Nobody ever loaded one of its conferences down with dozens of participants, though, so I can’t say we tested my sense of things, but FWIW, I’m pretty confident that performance would remain good all the way up to 75 participants, as long as most remained video off and muted.
3. There’s no point in telling people they shouldn’t want 50-70 full-video, full-audio simultaneous participants in a conference
(‘room’), because people want what they want, and, 41 years after VisiCalc, people are still insisting on using their spreadsheet programs for use-cases crying out for a database. However….
Let me put it this way: This year, my wife and I were supposed to go back to my college for my first reunion ever, my 40th: I’m an alumnus of Princeton, class of 1980. We got all ready to go, all paid up, and then the world fell apart, Princeton cancelled, and suddenly all 1,000 of us were invited to have a virtual reunion on Zoom, instead. About 200 of us actually did, and a Zoom conference with that many participants is truly ridiculous. The possibility for interaction was almost nil, though I did get the schadenfreude of letting my classmates see that I look great at age 62 and for me to see that most of them really don’t. Aside from that, all that saved it from being utter madness was the Zoom breakout-room feature, where I could mingle with 10 long-lost classmates instead of 200.
Jitsi Meet doesn’t have breakout rooms (though a subset of members can just decide move to a different room). But it does have livestreaming, a variant of what Zoom calls the webinar feature, where participants who don’t aspire to interact can see the conference, e.g., via a livestream to YouTube or a similar video streaming service.
But I’ll bet that even without resorting to livestreaming, you can scale up a Jitsi Meet room (with a beefy machine powering Jitsi Video Bridge) to 120 participants if the default is video-off, audio muted, and only a modest number of people, primarily the panelists, switched their cameras on.
Somehow, because the distribution default of Jiti Meet is that everyone enters a conference with video running, and because meet.jit.si evinces that default, almost everyone fails to realise you can trivially reverse that default by changing /etc/jitsi/meet/$FQDN-config.js from
startWithVideoMuted: false,
to
startWithVideoMuted: true,
Anyway, personally, I think wanting to run a room with over 35 simultaneously active video participants is kind of nuts — but I’m
aware that people think they need that because it doesn’t occur to them that there’s any different way. People want what they want.
[He asked me about performance of the server I constructed for the 2020 World Science Fiction convention in Wellington. I replied:]
To my surprise, CoNZealand’s Jitsi Meet instance (for Exhibits) ran with an extremely light load at all times — even though I never needed to even think of adding in more Jitsi Video Bridge instances (which I was prepared to do if we needed that for scaling). Getting the Zabbix stats would be enlightening, but every time I looked it was barely kicking over. (I’m sure ‘startWithVideoMuted: true,’ helped.)
I meant /etc/hosts, not /etc/aliases. Sorry about that.