Reliable videoconferencing
Conference Call
If you are looking for an alternative to commercial videoconferencing platforms, Jitsi offers an open source solution that lets you build and deploy online videoconferences.
Halfway through a phone conversation amid the doom and gloom of the global pandemic, someone complained about commercial online videoconferencing services creaking at the seams due to the massive increase in demand.
This led me to think about open source video conferencing options. After a little bit of reading, I discovered Jitsi [1], a truly impressive open source project for building and deploying secure videoconference services. Jitsi, courtesy of 8x8 Inc. [2], has an Apache2 license and includes Jitsi Meet [3], a free video conferencing platform, and Jitsi VideoBridge, a Selective Forwarding Unit (SFU) that powers multiperson videoconferencing. For an overview of the project, visit their website [4] or check out their GitHub page [5].
Jitsi offers secure and scalable videoconferences, either as a standalone app or embedded into your own web application. Jitsi has been around since 2003 in one incarnation or another, with continual fine tuning over recent years.
You do not need an account to start a video call with Jitsi, and it is very browser-friendly and mobile-compatible. Jitsi also allows screen sharing, voting with your hand, and online chat. In this article, I'll show you how to use Jitsi to create a fully encrypted, open source, free-to-use, videoconferencing service.
Getting Started
I'll walk you through what you need to get Jitsi up and running. Also, I'll assist in switching off as many network ports as possible so that you're only exposing the HTTPS port to the public, and I'll provide some fine-tuned firewall rules. To get an insight into all the features Jitsi offers, I will install the full suite of Jitsi software. You will be pleasantly surprised at how little the disk footprint is.
For my videoconferencing server, I'll use DigitalOcean [6], which refers to servers as "droplets." When creating the droplet, I'll ask the cloud platform to install Ubuntu 18.04 (Bionic Beaver) as it has a shelf life until April 2028. I'll assume that you can create a DigitalOcean account on your own. Setting up a droplet manually is easy – if you are new to DigitalOcean, visit their website for more information on setting up a droplet [7].
After logging in over SSH, run
apt update; apt upgrade -y
followed by a reboot to update the operating system software. After running the following command:
$ cat /etc/os-release
you will get the output shown in Listing 1, confirming that the server is running the correct Ubuntu version.
Listing 1
Confirming Operating System
NAME="Ubuntu" VERSION="18.04.4 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.4 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic
The next trick is to install Apache2 (or NGINX if you prefer). During installation, Jitsu will figure out which web server you are using and then work via that server. Install the Apache2 web server with:
$ apt install apache2
After entering the droplet's IP address into a browser, you will see that Apache2 is running as expected (Figure 1).
Next, I'll follow the installation instructions from Jitsi's website [8].
To ensure that I'm connecting to the right repository, as the root user, I'll set up the key for the Jitsi repository with the following:
$ wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add - OK
Then, I'll open up a file called /etc/apt/sources.list.d/jitsi-stable.list
and save the following line to it:
deb https://download.jitsi.org stable/
After that, I'll do a quick update as shown in Listing 2.
Listing 2
Connection to Jitsi Repository
$ apt update Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease Get:2 http://mirrors.digitalocean.com/ubuntu bionic InRelease [242 kB] Get:3 https://download.jitsi.org stable/ InRelease [2415 B] Hit:4 http://mirrors.digitalocean.com/ubuntu bionic-updates InRelease Hit:5 http://mirrors.digitalocean.com/ubuntu bionic-backports InRelease Get:6 https://download.jitsi.org stable/ Packages [36.4 kB] Fetched 281 kB in 1s (363 kB/s) Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date.
As you can see from the output in Listing 2, the Jitsi repo has been connected to as hoped and accessed without complaint following the key that I installed.
Installing Jitsi
I'm now ready to install the videoconferencing suite, barring some firewall tweaking. The commands in Listing 3 install the full package.
Listing 3
Installing Jitsi
$ apt install jitsi-meet ca-certificates-java fontconfig-config fonts-dejavu-core java-common jicofo jitsi-meet jitsi-meet-prosody jitsi-meet-web jitsi-meet-web-config jitsi-videobridge libavahi-client3 libavahi-common-data libavahi-common3 libcups2 libfontconfig1 libjpeg-turbo8 libjpeg8 liblcms2-2 libnspr4 libnss3 libpcsclite1 libxi6 libxrender1 libxtst6 lua-bitop lua-event lua-expat lua-filesystem lua-sec lua-socket lua5.1 openjdk-8-jre-headless prosody x11-common
As expected, the installation involves a reasonably large number of files, but it only takes about 215MB of extra space on my server. You might notice that the x11-common package will be installed; usually this package wouldn't be used on a headless server driven by the command line. Consequently, you might want to have this server dedicated to Jitsi.
The jitsi-meet package installs the whole suite, which I will do to show all of Jitsi's features. You also can just install the individual components you need as follows:
$ apt install jitsi-videobridge $ apt install jicofo $ apt install jigasi
Upon launching the jitsi-meet package, you will be asked for a hostname. Choose a sensible one. Assuming you own a domain name, create a DNS name (an A record) for your server's IP address to save time later. I've chosen this hostname:
call.chrisbinnie.tld IN A 123.123.123.123
Enter your hostname in the pop-up box and then choose Generate a new self-signed certificate on the next screen. (You will get a chance later to obtain a Let's Encrypt certificate.)
At this stage, screeds of data are flying up the terminal as the Jitsi software runs through its installation. Listing 4 shows the tail end of the output without errors before returning you to a prompt.
Listing 4
Generating a Self-Signed Certificate
Running hooks in /etc/ca-certificates/update.d... done. done. Processing triggers for ureadahead (0.100.0-21) ... Processing triggers for libc-bin (2.27-3ubuntu1) ...
Next Jitsi will auto-configure a Let's Encrypt certificate for free and associate it with your hostname. You need to wait for your DNS to become available (if your DNS isn't ready, then just run it again when the DNS is available) to run a sophisticated Let's Encrypt script. To confirm that your DNS is live, run this redacted command:
$ host -v -t a call.chrisbinnie.tld ns1.nameserver.tld
and then run the Let's Encrypt script:
$ /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
In this brief process, you're prompted for an email address. Then, as if by magic, certificates are mysteriously installed, taking all the configuration pain away (Listing 5).
Listing 5
Let's Encrypt Installation Successful
- Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/call.chrisbinnie.tld/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/call.chrisbinnie.tld/privkey.pem Your cert will expire on 2020-06-22. To obtain a new or tweaked version of this certificate in the future, simply run certbot-auto again. To non-interactively renew *all* of your certificates, run "certbot-auto renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le Configuring apache2
You can renew the certificate easily in the future by running the command again and look for the output as shown in Listing 5.
Firewall Rules
Your next step in to set up your firewall rules.
I won't lock down your SSH port to a specific IP address in this example, because I don't want you locked out mid-configuration. You can use iptables or even TCP Wrappers to lock down your SSH yourself. Once testing is finished, you also need to change the SSH port and harden your SSH daemon (if you wish).
In order to configure iptables from Netfilter, I'll first create a simple script, /root/iptables.sh
(Listing 6), and then make it executable with the command
chmod +x /root/iptables.sh
Listing 6
iptables.sh
01 # Clear old config first 02 iptables -P INPUT ACCEPT 03 iptables -P FORWARD ACCEPT 04 iptables -P OUTPUT ACCEPT 05 iptables -t nat -F 06 iptables -t mangle -F 07 iptables -F 08 iptables -X 09 10 # Drop inbound and forwarding but allow outbound 11 iptables -P INPUT DROP 12 iptables -P FORWARD DROP 13 iptables -P OUTPUT ACCEPT 14 15 # Allow localhost in/out 16 iptables -A INPUT -i lo -j ACCEPT 17 iptables -A OUTPUT -o lo -j ACCEPT 18 19 # Allow established traffic to flow 20 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 21 22 # Apparently Jitsi can use these ephemeral ports so allow them inbound 23 iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT 24 25 # Enable HTTPS access 26 iptables -A INPUT -p tcp --dport 443 -j ACCEPT 27 28 # Allow HTTP for Let's Encrypt temporarily 29 iptables -A INPUT -p tcp --dport 80 -j ACCEPT 30 31 # Change the default port in /etc/ssh/sshd_config from 22 after testing 32 iptables -A INPUT -p tcp --dport 2002 -j ACCEPT
so that I have a backup of my firewall rules.
These firewall rules are just an example, so you might need to adjust them according to your needs. You can always log in via the DigitalOcean console (in your browser) if you get stuck here and lose SSH access.
To run the script in Listing 6 enter:
$ /root/iptables.sh
To verify that the firewall rules are in place, use:
$ iptables -nvL
To make sure your custom iptables firewall rules persist after a reboot, install the very handy iptables-persistent package with:
$ apt install iptables-persistent
Then, choose yes to save IPv4 rules and select no for IPv6 rules as there aren't any. A quick reboot is needed to check that you can still get back into the server by SSH.
If I run the iptables -nvL
command again to verify that the firewall rules have persisted, I will see the output displayed in Listing 7.
Listing 7
Firewall Rules Persist
Chain INPUT (policy DROP 23 packets, 1768 bytes) pkts bytes target prot opt in out source destination 174 24898 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 65 7817 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 4 1095 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 62 packets, 9148 bytes) pkts bytes target prot opt in out source destination 174 24898 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
In short, the rules in Listing 7 mean that outbound traffic is allowed. However, inbound traffic is only permitted if it's part of a conversation already taking place and HTTP is open (close this soon after you finish testing since the script leaves it open, but note that your LetsEncrypt certificate refreshes need this port open) as well as HTTPS and SSH ports (which you should lock down yourself and change the port number). UDP ports are also enabled for ephemeral connections in the 10000-20000 range (this may not be required).
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.