Run a FOSS, 64-bit Jitsi Meet Videoconferencing Server on your RPi4!
Hello,
If you're looking for a secure,
FOSS alternative to Zoom, Hangouts etc. for
video-conferencing, you may have come across
Jitsi Meet, an Apache-licensed WebRTC-based solution. It has a client that runs purely in your web browser (with native Android and iOS clients also available), coupled with a back-end server complex that performs forum management, selective video forwarding, NAT traversal etc. The source is available
here, and you can quickly try Jitsi, with no password needed, at
https://meet.jit.si
Unfortunately however, setting up your
own Jitsi server instance is somewhat complex, due to the requirement to
cross-sectionally configure a group of services, integrate with Let's Encrypt (for certificate management) etc. While Debian has a multi-component, debconf-guided solution for this (
curated by upstream), Gentoo currently does not (in tree anyhow).
To help address this, I have recently put together a
set of ebuilds in my sakaki-tools overlay which covers the core Jitsi service set,
including a pkg_config step that mirrors the flow of upstream's debconf / postinst logic, providing an easy, prompt-based setup for single-box installs. The ebuilds support both
OpenRC and
systemd, allow for use of either
nginx (preferred) or
apache as the webserver, and are available on
~amd64 (x86_64) and
~arm64 (aarch64). The server-side Java components are built from source (*) using the provided
java-maven-pkg eclass. Automated TLS certificate issuance (and renewal) via
Let's Encrypt is supported, but not mandated. Starting a
new video-conference is set up to require a password by default
(and once created, you can then add a password to that particular conference at your option, before distributing the URL to others).
I have built and pushed the necessary binary packages to the binhost, and made required changes to masks etc in the custom profile, so now you can easily install your own Jitsi server instance on an RPi4 running gentoo-on-rpi-64bit! (Of course, you can also build from source if you wish, rather than using the binhost.) A 2GiB RPi4 is realistically the minimum system to use here
(NB: because Jitsi does not process the video streams, but acts simply as a meeting coordination point, selective forwarding unit and TURN server, the CPU requirements are not onerous - an RPi4 should be able to handle a reasonable number of simultaneous participants).
To get started, first follow 'RPi4 64-bit Gentoo Install' instructions below. Once done, follow the 'Jitsi Configuration and Bring-Up' instructions next.
Should you wish to have your Jitsi server start automatically on boot, finally follow the 'Starting Jitsi Automatically' instructions.
Have fun, and please report any issues either in this thread (preferred) or via email to
sakaki@deciban.com!
best,
sakaki
PS: if you are instead looking for a quick way to get an x86_64 Gentoo Jitsi server up and running, you might like to take a look at my nspawn-gentoo-jitsi-meet project on GitHub!
RPi4 64-bit Gentoo Install
Prerequisites: you have an RPi4 running gentoo-on-rpi-64bit. It has a dedicated IPv4 address (IPv6 should be supported too, but I haven't fully tested it), and at least 2GiB of RAM. Ideally, for stability your external IP connection is via Ethernet. You have registered a domain name (we will use, purely as an example, foo.barfoo.org in what follows) that resolves (via A record) to the IP address of your RPi4 mini-server: you can ping foo.barfoo.org from an external machine and your RPi answers successfully. No web, prosody, turn, videobridge or jicofo server should currently be running on the target RPi4. Ports 80/tcp, 443/tcp, 4445/tcp, 4446/udp and 10000/udp must be open.
OK, to begin, update the overlays:
Code: Select all
pi64 ~ # emaint sync --repo sakaki-tools
pi64 ~ # emaint sync --repo genpi64
With that complete, you're ready to emerge the various component servers (jicofo, jitsi-videobridge, coturn etc)! To do so, simply issue:
Code: Select all
pi64 ~ # emerge -v --noreplace net-im/jitsi-meet-server
This package, and all deps, should be available as binary packages on the binhost (if your system is relatively up-to-date), so this shouldn't take too long (compile from source is possible too, but takes about 45mins or so). Assuming it completes OK, congratulations, you are now able to proceed with configuring and bringing up your Jitsi Meet server instance! Continue reading immediately below.
Jitsi Configuration and Bring-Up
Configuration of the Jitsi server complex is done by following a prompt-driven process to fill out a 'master' configuration file (/etc/jitsi/jitsi-meet-master-config; this is a little like the
'env' file in the Docker variant of Jitsi Meet). A set of hooks, one per component, are then automatically invoked to build the underlying configurations (and associated setup steps) for jitsi-videobridge, jicofo, the webserver etc. This ensures that passwords, UUIDs etc. are consistent across all components.
Of course, the underlying blocks may also be configured directly by those who are knowledgeable about Jitsi's 'wiring', and indeed non-single-box installs will require you to do so. But the point of the approach taken here is to help you get a simple instance up and running with the minimum of hassle.
In what follows, I'm going to assume you have a DNS 'A' record pointing to your RPi4, IP address 82.221.139.201, with fully-qualified domain name (FQDN) of foo.barfoo.org — obviously, adapt this for your actual system.
NB: it is possible to reconfigure the server complex any number of times. So you could create a localhost-based version initially for testing, and then migrate to an externally visible version. Or redeploy an existing version to create fresh passwords etc. Up to you!
OK, so now, issue:
Code: Select all
pi64 ~ # emerge --config jitsi-meet-master-config
and you should be prompted to enter the answers to various questions. In what follows, you can simply press Enter to accept the offered default (shown in square brackets) or, type a different answer and then press Enter. The configuration process provides quite a lot of explanatory text for each question but, in the interests of brevity, in the below only the questions (and responses) will be shown.
Remember, this for the (notional) domain foo.barfoo.org, at IP address 82.221.139.201, administrative email
your@email.address; obviously, adapt for your own system!
Here's a full flow (minus commentary); parts you may or may not see (depending on whether or not it is the first time you are running the config) are shown in parentheses:
Code: Select all
pi64 ~ # emerge --config jitsi-meet-master-config
(* Re-use existing configuration for ...? (y/n) [n]: <press Enter>)
* Hostname [...]: <type foo.barfoo.org and press Enter>
* External IP address [...]: <type 82.221.139.201 and press Enter>
* Internal IP address [...]: <type 82.221.139.201 and press Enter>
* Create a localhost alias for foo.barfoo.org? (recommended) (y/n) [y]: <press Enter>
* Copy foo.barfoo.org into "/etc/hostname"? (recommended) (y/n) [y]: <press Enter>
* Max videobridge daemon RAM [1024m]: <press Enter>
* Username [admin]: <press Enter>
* Password [horse-battery-staple]: <press Enter - your generated password will differ>
* Supply pre-existing key/crt pair for foo.barfoo.org? (y/n) [n]: <press Enter>
* Activate Let's Encrypt for foo.barfoo.org? (y/n) [y]: <press Enter>
* Email address [...]: <type your@email.address and press Enter>
* Configuration complete: write it? (y/n) [y]: <press Enter>
* Build component configurations from this? (y/n) [y]: <press Enter>
It is possible to reconfigure the server any number of times.
Once the underlying component configuration completes, you can try starting up your new Jitsi Meet server instance!
To do so, issue:
Code: Select all
pi64 ~ # rc-service jitsi-meet-server restart
This will start the various component servers (nginx, jitsi-videobridge, jicofo, turnserver/coturn and prosody).
Startup will take about five seconds. Once done, you should be able to browse to
https://foo.barfoo.org (remember, this is just a
fictional example, use your own FQDN!) from any remote machine and start a new meeting (click GO)! If all is well, you should find that the browser reports a valid TLS certificate ('padlock' symbol) issued by Let's Encrypt.
An automatic renewal job is also scheduled for you, which will keep this certificate up-to-date, restarting the webserver and turnserver as required.
In the browser, allow use of your camera / microphone when prompted, and then click on "I am the host" in the pop-up dialog which appears, and use the credentials above (in this example "admin" / "horse-battery-staple" (without quotation marks); obviously, adapt as appropriate). The new meeting will start, and you will see yourself on screen. You should then be able to send the meeting URL (click the circular (i) icon at the bottom of the window to see it, or look in your browser address bar) to others to enable them to join - they will not require these credentials (however, you
can set a 'room' password before inviting any guests, if you wish, again via the circular (i) icon). Note that as you have an externally valid TLS certificate, users can
also join via the official Android or iOS Jitsi apps.
To allow Android or iOS app users to initiate new meetings, you'll need to have them add your host address (in this example, https://foo.barfoo.org/) in the Server URL field, under the settings tab of the app (you will also need to let them know the convener credentials — here, "admin" / "horse-battery-staple").
Should you wish to bring the server complex down at any point, issue:
Code: Select all
pi64 ~ # rc-service jitsi-meet-server stop
Logs may be viewed at /var/log/jitsi/... , and in /var/log/messages.
Starting Jitsi Automatically
Once you have your Jitsi server instance working well, you may decide you want to start it up automatically whenever your RPi4 reboots.
To do so, issue:
Code: Select all
pi64 ~ # rc-update add jitsi-meet-server default
Acknowledgement: thanks to all the participants on this GitHub thread for showing how to get jitsi-sctp building on aarch64.
(*) This approach - inspired with thanks by net-p2p/bisq-0.6.3.ebuild - builds the top level (Java) code for sctp, jicofo, and jitsi-videobridge from source, but still pulls in a large number of upstream jars as dependencies. Chasing through all of these to bring them into Portage is certainly possible but way too much work for the scope of this project. Where existing ebuilds exist in Portage, they can be used (as demonstrated e.g. by the dom4j example), and the bundled mvn2ebuild utility makes it relatively straightforward to convert a working maven Java build to an ebuild.
On the web application side, I have just used the upstream deb and unpacked the (compiled) webroot. The is no live server-side content (all that is done via the other components, jicofo, prosody and jitsi-videobridge), and the client-served content is either minified JavaScript or WebAssembly. It is straightforward to build your own webroot if desired (see e.g. here) but unfortunately the use of npm (coupled with interlinked git repos) makes it difficult to port straightforwardly into an ebuild (npm really doesn't want to run offline when using git ><).