How-to to setup integrated Jitsi and Jibri for dummies, my comprehensive tutorial for the beginner

Installation of Jitsi Meet with Jibri on 2 servers with Debian 10 (buster) cloud VM’s.

In this post, I will describe my steps to get a working setup of Jitsi Meet video conferencing with integrated Jibri recording and streaming. All steps are based on the readme instruction on Github with some additions and/or modifications.

Jitsi quick install document on Github: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
Jibri setup document on Github: https://github.com/jitsi/jibri/blob/master/README.md

I will try to clarify these differences as well as I can. Please bear in mind: I consider myself a total newbee to linux; I enterd my first linux commands about 3 months ago. Maybe there are better practises to achieve my adaptations and I will appreciate your feedback and will try update this document in the weeks to come.

For clarity:

  • JITSI. When I speak of server: “jitsi”, this will be the server to host the jitsi meet services, your video conferences will be hosted on this server and your participants will connect to this server.
  • JIBRI. When I speak of server: “jibri”, this will be the server to host the jibri recording and streaming service. This server will connect to the “jitsi” server and host the recordings or stream the video to youtube.

In this document I will:

Step 1) Show or describe the process to register a server at Hetzner. [done 15/4]
Step 2) Show or describe how to register the domain for your Jitsi Meet, I will use my domain through the whole document. [done 15/4]
Step 3) Describe the process to setup a working Jitsi Meet on one server, including some tweaks and tuning. Installing Jibri is not necessary, the Jitsi Meet server is ready for use. [done 15/4]

Tuning A) Solve Prosody portmanager error [done 15/4]
Tuning B) Improving over-all performance by sacrificing audio indication animation [done 15/4]
Tuning C) Video resolution and bitrate [done 15/4]
Tweaking A) Layout changes (will not be overwritten by upgrade) [done 15/4]

Step 4) Describe the process to setup a working Jibri on a second server, including some tweaks and tuning.
Step 5) Describe the process to integrate JITSI and JIBRI, this will require changes on both servers. When finished, you will be able to host Jitsi Meet conferences and start recording or streaming.

Final result will look like:

Step 1) Register a server at Hetzner.
Hetzner currently offers a cheap virtual server for approx. 2.50 USD (3 EUR). Although this is very low in specifications, Jitsi Meet will run and I have successfully hosted jitsi meet conferences up to 6 participants. Server specifications: 1 vCPU, 2 Gb RAM, 20 Gb Disk space, 20 Tb Traffic. (https://www.hetzner.com/cloud --> Server package: CX11) Register at Hetzner or login directly to: https://console.hetzner.cloud/projects

Create or Choose the project you want and Click on ADD SERVER,

  1. location as you see fit
  2. Image: Debian 10
  3. Type: Standard CX11
  4. ~ 7): leave empty or default
  5. Name: jitsi

REMARK: I advise to use SSH key login but for this document I will assume user/password login. All commands in this document will assume root-login, of course this is not best practice: I leave it to the reader to apply these steps with a separate user with root-rights! :wink:

My server got:
IPv4: 116.203.231.172
IPv6: 2a01:4f8:c0c:d4cc::/64
In email I received the password for root user: RcHE7PcmWPpENjWHtkUW (you will be prompted to change this password at first login)

Step 2) Register a domain for your Jitsi Meet conferences.
There are quite many free DNS registration services out there, maybe you have one in use already. In the course of this document, I will use the free Dynamic-DNS-Service of Securepoint: https://www.spdyn.de/ (I was unable to find an english version of the site). After registering (only requires valid email address and choose your password) and login (You can change language in the dashboard by adding to the URL: ?changeLang=en), I choose:
Click: + Add ipv4 host

  • Name: meet & from dropdown I choose “myfirewall.org
  • Host Type: A (to register a so called A-Record)
  • IP: the IPv4-Address from the Hetzner server in step 1, in my case: 116.203.231.172
    Finish by clicking on button “Add host”


Now I have a dns name, meet.myfirewall.org

On my laptop, I can open a command prompt and ping meet.myfirewall.org to check if the response matches the IPv4-Address of my Hetzner server:

Step 3) Setup Jitsi Meet on the server.
You will need to login to the server you created in step 1. For this, on my Windows laptop, I use PuTTy. Login with initial password and change it to your own.

Update server:

apt update && apt upgrade -y

Check / take care of the hostname (Here, I will provide some more information here than in the ‘quick install’ guide)

hostnamectl

In my case, I find: Static hostname: ‘jitsi’ – I want to change jitsi to: meet.myfirewall.org

hostnamectl set-hostname meet.myfirewall.org

Configure loopback address

nano /etc/hosts

I got 2 entries for the 127.x.x.x range:
127.0.1.1 meet.myfirewall.org jitsi
127.0.0.1 localhost

So I removed the first line (127.0.1.1) and made sure to have only one line for 127.x.x.x:
127.0.0.1 localhost meet.myfirewall.org

Save the changes and go back to the terminal, type following:

ping "$(hostname)"

Check that the ping results in a lookup for meet.myfirewall.org and the answers return from 127.0.0.1.

Install NGINX
If Jitsi Meet gets installed on a fresh server, it will install it’s own webserver (Jetty) in the process. From what I find in the forums, I prefer to go with NGINX, so let’s install that first. In the terminal:

apt install nginx -y

Hint: We do NOT have to configure anything for NGINX: the jitsi-installer will take care of that!

Debian 10 SHOULD come with https-transport extension pre-installed, if yours does not:

apt install -y apt-transport-https

Install Jitsi Meet
First we need to add the repositories where our server should retrieve the Jitsi Meet packages, in the terminal:

echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
apt update && apt install jitsi-meet -y

During installation we can expect 2 questions:

Domain - Here I enter the full domain: meet.myfirewall.org


Certificate - Leave this option at the default to install Let’s Encrypt certificates afterwards.

Generate Let’s Encrypt certificates for our domain

-UPDATE-
Currently, the build is broken and at the end of the process it shows error message:
Unable to find deploy-hook command /etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh in the PATH.
(PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

As a workaround we can do following:

mkdir -p /etc/letsencrypt/renewal-hooks/deploy/
touch /etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh
chmod +x /etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh

Execute the Let’s Encrypt script:

/usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

The script will ask for your email address where Let’s Encrypt will send information in case of expiration -date or such.

At this point you should have a working Jitsi Meet server!
Open a browser and enter the domain of your Jitsi Meet, I open https://meet.myfirewall.org and get greeted by the welcome screen. Here I create a new meeting ‘test’ and open a conference (make sure to ALLOW the browser to use microphone and camera). I always open an incognito window and open the same meeting I initiated already: https://meet.myfirewall.org/test so there should now be 2 participants in the call. Opening a 3rd browser to that same meeting ensures that we know if Jitsi switches from peer2peer mode to videobridge mode. When 3 participants are showing in the call, we know all is well so far.

Install and configure a firewall on the server
I will use the firewall ‘ufw’ for this server:

apt install ufw -y

Make sure to execute these lines in this order to avoid getting your ssh-connection shut-out by the firewall:

ufw allow ssh
ufw allow http
ufw allow https
ufw allow 10000/udp
ufw enable

Tweaking and tuning

Tuning A) Prosody portmanager error

service prosody status

(type ‘q’ to quit the output console)

Output:
● prosody.service - Prosody XMPP Server
Loaded: loaded (/lib/systemd/system/prosody.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-04-15 19:39:18 CEST; 32min ago
Docs: https://prosody.im/doc
Main PID: 16994 (lua5.2)
Tasks: 1 (limit: 2296)
Memory: 18.5M
CGroup: /system.slice/prosody.service
└─16994 lua5.2 /usr/bin/prosody

Apr 15 19:39:18 meet.myfirewall.org systemd[1]: Started Prosody XMPP Server.
Apr 15 19:39:19 meet.myfirewall.org prosody[16994]: portmanager: Error binding encrypted port for https: No certificate
Apr 15 19:39:19 meet.myfirewall.org prosody[16994]: portmanager: Error binding encrypted port for https: No certificate

The portmanager error basically is harmles and can be ignored. But we can also fix this.

nano /etc/prosody/conf.avail/meet.myfirewall.org.cfg.lua

Before the first Virtualhost entry, insert following:

-- we are going to be proxying the BOSH connection anyway, so there is no need to be listening for BOSH over HTTPS
https_ports = { }


Save the changes and restart prosody, all should be happy now:

service prosody restart
service prosody status

Tuning B) Improving over-all performance by sacrificing audio-indicator animation

nano /etc/jitsi/meet/meet.myfirewall.org-config.js

Find the audio-section and set:

disableAudioLevels: true,

With this setting, you loose the visually appealing sound level indicators/animations in the call, but this also removes a lot of overhead and screen-rewriting. On this rather poor-dimensioned server, this brings a noticable performance gain.

Found here: [Customizing jitsi -- viewer only -- bandwidth -- usecase]

Tuning C) Video resolution and bitrate
Jitsi Meet sends 720p resolutions with 30 fps (at least afaik).
Google’s recommendations are:
Resolution: 1280x720 @ 30 fps
Video Bitrate Range: 1,500-4,000 Kbps

I have tested several scenarios with setting the ‘startBitrate’ to a low level and found good results with following:

nano /etc/jitsi/meet/meet.myfirewall.org-config.js

Find the video-section and insert:

startBitrate: 500,
resolution: 720,
constraints: {
video: {
aspectRatio: 16 / 9,
height: {
ideal: 720,
max: 720,
min: 240
}
}
},

Tweaking A) Some layout changes (will not be overwritten by upgrade)
I had the intention to change the logo. The logo is located in the usr-space /usr/share/jitsi-meet/images/ so I replaced it with my own. This worked until next upgrade, so I found to do it with a workaround. I uploaded my own logo to: /etc/jitsi/meet/woodworkerlogo.png also uploaded the favicon to the same location: /etc/jitsi/meet/favicon.ico. I downloaded the css-file /usr/share/jitsi-meet/css/all.css and used an online service (https://www.freeformatter.com/css-beautifier.html) to ‘beautify’ the content so it would become readable. I renamed the file to myfirewall.css and uploaded also to the location: /etc/jitsi/meet/myfirewall.css. After these preparations it was time to modify NGINX to serve these files from their new location:

nano /etc/nginx/sites-available/meet.myfirewall.org.conf

I inserted following lines below the gzip-declarations and before the first existing location-block to serve the new logo, favicon and css from their new location:

...
gzip on;
gzip_types text/plain text/css application/javascript application/json;
gzip_vary on;

location = /css/all.css {
alias /etc/jitsi/meet/myfirewall.css;
}

location = /images/favicon.ico {
alias /etc/jitsi/meet/favicon.ico;
}

location = /images/watermark.png {
alias /etc/jitsi/meet/woodworkerlogo.png;
}

location = /config.js {
alias /etc/jitsi/meet/meet.myfirewall.org-config.js;
}
...

I applied some changes to the new myfirewall.css file: only to change the color-scheme:

A)
Original: background-image: linear-gradient(-90deg, #1251AE 0, #0074FF 50%, #1251AE 100%);
Myfirewall: background-image: linear-gradient(-90deg, #047500 0, #069E00 50%, #047500 100%);

B)
Original: .welcome .welcome-page-button - background: #0074E0;
Myfirewall: .welcome .welcome-page-button - background: #069E00;

C)
Original: .welcome .header .tab-container - background:#75A7E7;
Myfirewall: .welcome .header .tab-container - background: #07C200;

D)
Original: .tile-view #largeVideoContainer {
background-color: #474747!important
}
Myfirewall: .tile-view #largeVideoContainer {
background-color: #069e00!important
}

E)
Original: .meetings-list .item.with-click-handler:hover {
background-color: #75A7E7
}
Myfirewall: .meetings-list .item.with-click-handler:hover {
background-color: #07C200
}

After these changes are saved, we need to restart NGINX:

service nginx restart

The new logo, favicon and page-layout should now display in the Jitsi Meet pages and chat. If it does not show, you will need to flush the images-cache in your browser. (to flush favicons in chrome on windows: open ‘C:\Users[your_user]\AppData\Local\Google\Chrome\User Data\Default’, delete both files ‘Favicons’ and ‘Favicons-journal’ and restart your chrome browser)

Cheers, Igor

16 Likes

Installation of Jibri on Debian 10 (buster) server VM.

In this post, I will describe my steps to get a working setup of Jibri video recording. All steps are based on the readme instruction on Github with some additions and/or modifications.

I will try to clarify these differences as well as I can. Please bear in mind: I consider myself a total newbe to linux; I enterd my first linux commands about 3 months ago. Maybe there are better practises to achieve my adaptations and I will appreciate your feedback and will try update this document in the weeks to come.

For clarity:

  • JITSI. When I speak of server: “jitsi”, this will be the server to host the jitsi meet services, your video conferences will be hosted on this server and your participants will connect to this server.
  • JIBRI. When I speak of server: “jibri”, this will be the server to host the jibri recording and streaming service. This server will connect to the “jitsi” server and host the recordings or stream the video to youtube.

In this document I will:
Step 1) Register a server at Hetzner.
Step 2) Register the domain for Jibri, I will use my domain through the whole document.
Step 3) Describe the process to setup a working Jibri recorder on one server.
Detail: JAVA 8 Jibri requires JAVA 8 but this is depricated for Debian 10, I will provide a workaround.

Step 1) Register a server at Hetzner.
I follow the same steps as described in my first post.

Create or Choose the project you want and Click on ADD SERVER,

  1. location as you see fit
  2. Image: Debian 10
  3. Type: Standard CX11
  4. ~ 7): leave empty or default
  5. Name: Jibri
    REMARK: I advise to use SSH key login but for this document I will assume user/password login.

My server got:
IPv4: 116.203.20.99
IPv6: 2a01:4f8:c0c:b59e::/64
In email I received the password for root user: pVT9eKNJ7uxCJtv43d3W (you will be prompted to change this password at first login)

Step 2) Register a domain for your Jibri recorder.
I follow the same steps as described in my first post.

  • Name: recording & from dropdown I choose “myfirewall.org
  • Host Type: A (to register a so called A-Record)
  • IP: the IPv4-Address from the Hetzner server in step 1, in my case: 116.203.20.99
    Finish by clicking on button “Add host”


Now I have a dns name, recording.myfirewall.org

On my laptop, I can open a command prompt and ping recording.myfirewall.org to check if the response matches the IPv4-Address of my Hetzner server.

Step 3) Setup Jibri on the server.
You will need to login to the server you created in step 1. For this, on my Windows laptop, I use PuTTy. Login with initial password and change it to your own.

Update server:

apt update && apt upgrade -y

Check / take care of the hostname (I will provide some more information here than in the ‘quick install’ guide)

hostnamectl

In my case, I find: Static hostname: Jibri – I want to change jitsi to: meet.myfirewall.org

hostnamectl set-hostname recording.myfirewall.org

Configure loopback address

nano /etc/hosts

I got 2 entries for the 127.x.x.x range:

127.0.1.1 meet.myfirewall.org jibri
127.0.0.1 localhost

So I removed the first and made sure to have only one line for 127.x.x.x:

127.0.0.1 localhost meet.myfirewall.org

Save the changes and go back to the terminal:

ping "$(hostname)"

This should request ping of recording.myfirewall.org returning answers from 127.0.0.1.

Detail: JAVA 8 (Jibri requires JAVA 8)

-IMPORTANT!-

When following the Jibri setup document on Github, you would install with: apt install default-jre-headless which results in the latest java (currently version 11) on the server and Jibri WILL NOT WORK. So as a first step, I make sure that Java is NOT installed on the server yet:

java -version

This should return: -bash: java: command not found

I will install JAVA 8 from AdoptOpenJDK Repo, first we make sure to have all dependencies onboard:

apt update && apt install wget gnupg software-properties-common -y

Now we can add the AdoptOpenJDK Repo:

wget -qO - https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | sudo apt-key add -
add-apt-repository --yes https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/

And install AdoptOpenJDK JAVA 8:

apt update && apt install adoptopenjdk-8-hotspot -y

Check the Java version:

java -version

This should return:

openjdk version "1.8.0_242"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.242-b08, mixed mode)

For some applications, it is important to set the correct Java Home Environment Variable variable. I’m not sure if this is required for Jibri, but I will do this in any case, if just for good practise.

update-alternatives --config java'

This should return:

There is only one alternative in link group java (providing /usr/bin/java): /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java
Nothing to configure.

(In case you HAVE 2 versions of Java installed, you could try to set version 8 as the active version. I did not try if this works for Jibri.)

The returned console output shows us the path to JAVA 8 and we will copy this to set the Java Home Environment Variable variable:

nano ~/.bash_profile

Paste the following line (make sure to use the path that was returned in previous step):

export JAVA_HOME=/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java

Save this and then source the file:

source ~/.bash_profile

And check the Java Home:

echo $JAVA_HOME

This should return:

/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java

This takes care of JAVA 8 for Jibri, now we can follow the main steps of the Jibri setup document on Github with some carefull amendments

Miscelaneous packages

We will install all miscelaneous packages EXCEPT default-jre-headless:

apt update && install unzip ffmpeg curl alsa-utils icewm xdotool xserver-xorg-input-void xserver-xorg-video-dummy -y

ALSA and Loopback Device

Set up the module to be loaded on boot:

echo "snd-aloop" >> /etc/modules

Load the module into the running kernel:

modprobe snd-aloop

Check to see that the module is already loaded:

lsmod | grep snd_aloop

This should return (something like):

snd_aloop              28672  1
snd_pcm               114688  1 snd_aloop
snd                    94208  5 snd_timer,snd_aloop,snd_pcm

Google Chrome stable & Chromedriver

Install the latest Google Chrome stable build:

curl -sS -o - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add
echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list
apt update && apt install google-chrome-stable -y

Add chrome managed policies file and set CommandLineFlagSecurityWarningsEnabled to false. It will hide warnings in Chrome. You can set it like so:

mkdir -p /etc/opt/chrome/policies/managed
echo '{ "CommandLineFlagSecurityWarningsEnabled": false }' >>/etc/opt/chrome/policies/managed/managed_policies.json

Chromedriver is also required and can be installed like so:

CHROME_DRIVER_VERSION=`curl -sS chromedriver.storage.googleapis.com/LATEST_RELEASE`
wget -N http://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip -P ~/
unzip ~/chromedriver_linux64.zip -d ~/
rm ~/chromedriver_linux64.zip
mv -f ~/chromedriver /usr/local/bin/chromedriver
chown root:root /usr/local/bin/chromedriver
chmod 0755 /usr/local/bin/chromedriver

Jitsi/Jibri Debian Repository

The Jibri packages can be found in the stable repository on downloads.jitsi.org:

wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
apt update && apt install jibri -y

We want to make sure that user ‘jibri’ is part of the necessary groups:

usermod -aG adm,audio,video,plugdev jibri

With these steps, we have now the basic setup of Jibri done, but the service is not active (yet).
Before starting the Jibri service, we have to make sure that both servers “jitsi” and “jibri” get configured, so that they ‘know’ of each other’s existence. This configuration will be explained in the next post.

Cheers, Igor

7 Likes

Configuring Jitsi and Jibri on Debian 10 (buster) server VM.

In this post, I will describe my steps to get a working setup of Jibri video recording. All steps are based on the readme instruction on Github with some additions and/or modifications.

I will try to clarify these differences as well as I can. Please bear in mind: I consider myself a total newbe to linux; I enterd my first linux commands about 3 months ago. Maybe there are better practises to achieve my adaptations and I will appreciate your feedback and will try update this document in the weeks to come.

For clarity:

  • JITSI. When I speak of server: “jitsi”, this will be the server to host the jitsi meet services, your video conferences will be hosted on this server and your participants will connect to this server.
  • JIBRI. When I speak of server: “jibri”, this will be the server to host the jibri recording and streaming service. This server will connect to the “jitsi” server and host the recordings or stream the video to youtube.

Describing the mechanisms (in a nutshell)
a) We now have a working Jitsi Meet server and we are able to setup videoconference meetings with multiple participants. In order to enable recording of such videoconference meeting, we would need some sort of a participant to join the meeting in the background just like any other participant and grab the screen- and audio information, mix it, compress it, format it to a file that we can play in a video player like vlc or do the same but stream it to youtube. For this, the Jitsi team has created the Jibri server.
b) The Jibri server is installed with screen functionality (chrome browser and -driver) and with audio/video compression software (ffmpeg) and although the sever never really opens the chrome browser for us to view, it does launch all the chrome browser components so it can use the same functionality as any other participant in our videoconference meeting to login to the Jitsi server and participate in the background. When it is told to actually record- or stream the conference, it will grab all the information that is also seen by the other participants and send this to the ffmpeg services for processing.

Configuring Jitsi Meet to allow Jibri to connect and ‘participate’ in any videoconference.

In general, we will be touching 3 area’s for this:

  • Prosody (this as the background xmpp server. You can imagine this to be similar like an instan-messaging backend service)
  • Jicofo (this is another background service which takes care of switching/relaying the processes between all participants and the videobridge)
  • Jitsi Meet (consider this as the master service which takes care of presenting all functionality in your webbrowser)

Everything below this section needs to be changed on server “jitsi”: “meet.myfirewall.org


Prosody configuration

Create the internal Multi User Component (MUC) and the the recorder virtual host entry, login to server “jitsi” and:

nano /etc/prosody/conf.avail/meet.myfirewall.org.cfg.lua

At the end of this file, add a dedicated section:

-- internal muc component, meant to enable pools of jibri and jigasi clients
Component "internal.auth.meet.myfirewall.org" "muc"
    modules_enabled = {
	    "ping";
    }
    storage = "memory"
    muc_room_cache_size = 1000
	
VirtualHost "recorder.meet.myfirewall.org"
    modules_enabled = {
        "ping";
    }
    authentication = "internal_plain"

Reload prosody:

/etc/init.d/prosody reload

Create two users for Jibri (user: jibri and user: recorder):

prosodyctl register jibri auth.meet.myfirewall.org JibrisPass
prosodyctl register recorder recorder.meet.myfirewall.org RecordersPass

(Important: take note of these passwords, we will need them later also on server “jibri”!)

Jicofo configuration

Set the Multi User Component (MUC) to look out for Jibri:

nano /etc/jitsi/jicofo/sip-communicator.properties

In this file, add two lines:

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.meet.myfirewall.org
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

image

Reload jicofo:

/etc/init.d/jicofo reload

Jitsi Meet configuration

Make sure we have the button for recording and/or streaming in our config:

nano /etc/jitsi/meet/meet.myfirewall.org-config.js

Look for following lines, uncomment the line and set value to ‘true’ or add if the line does not exist:

fileRecordingsEnabled: true, // If you want to enable file recording
liveStreamingEnabled: true, // If you want to enable live streaming
hiddenDomain: 'recorder.meet.myfirewall.org',

Make sure we have the menu-option for recording and streaming available:

nano /usr/share/jitsi-meet/interface_config.js

Look for the section TOOLBAR_BUTTONS and make sure that the array contains ‘recordings’ and ‘livestreaming’.

Configure firewall port 5222:

ufw allow 5222/tcp

This is all we need to do on server “jitsi”.


Everything above this section needs to be changed on server “jitsi”: “meet.myfirewall.org



Everything below this section needs to be changed on server “jibri”: “recording.myfirewall.org


We need to configure the xmpp environments and the directory where we want to store our recordings:

nano /etc/jitsi/jibri/config.json

Change settings according to:

{
    "recording_directory":"/srv/recordings",
    "finalize_recording_script_path": "/path/to/finalize_recording.sh",
    "xmpp_environments": [
        {
            "name": "prod environment",
            "xmpp_server_hosts": [
                "meet.myfirewall.org"
            ],
            "xmpp_domain": "meet.myfirewall.org",
            "control_login": {
                // The domain to use for logging in
                "domain": "auth.meet.myfirewall.org",
                // The credentials for logging in
                "username": "jibri",
                "password": "JibrisPass"
            },
            "control_muc": {
                "domain": "internal.auth.meet.myfirewall.org",
                "room_name": "JibriBrewery",
                "nickname": "jibri-nickname"
            },
            "call_login": {
                "domain": "recorder.meet.myfirewall.org",
                "username": "recorder",
                "password": "RecordersPass"
            },
            "room_jid_domain_string_to_strip_from_start": "conference.",
            "usage_timeout": "0"
        }
    ]
}

Now we create the directory for the recordings and make sure user ‘jibri’ can write here:

mkdir /srv/recordings
chown jibri:jitsi /srv/recordings

Restart jibri service:

service jibri restart

This is all we need to do on server “jibri”.


Everything above this section needs to be changed on server “jibri”: “recording.myfirewall.org


Testing recording

Once all these changes were in place, I even rebooted both servers. On the server “jibri”, the jibri service does not automatically start, so keep in mind to do so manually if needed.

Now I open my https://meet.myfirewall.org/ and start a meeting ‘test’. Once I Am presented with my videostream, I open the menu and choose ‘Start recording’. After some time to load, the recording was started. So after some seconds, I open the menu again and choose ‘Stop recording’.

On the server, I found the mp4 file of the recording in a sub-folder with a random generated folder-name:

/srv/recordings/oinwsjahyibvtnxk/test_2020-04-16-19-19-20.mp4

image
Mission accomplished!

Cheers, Igor

ps: I will not go over the streaming option as there is a good introduction available by youtuber Roberto A. Lineros:

5 Likes

Troubleshooting steps - Jitsi and Jibri.

So now we have a server for Jitsi Meet and possibly also anotherone with Jibri and we expect to start videoconferences, recordings and youtube-streams… OR AT LEAST WE THINK WE HAVE!

If things go awry, then the search is on! It is one thing to try the black box and if it doesn’t work (or part of it doesn’t) start searching the community forum or your favorite search engine. It is more helpful to find more specific information from the logfiles that are generated. It is important to understand the services that are involved:

Jitsi Meet

This server depends mainly on 3 services: prosody, videobridge2 (sometimes called jvb) and jicofo. After server reboot, these services should start in order like:

/etc/init.d/prosody start
/etc/init.d/jitsi-videobridge2 start
sleep 5
/etc/init.d/jicofo start

When the server is running, we can check their status and the results look something like:

service prosody status
Shows:

● prosody.service - Prosody XMPP Server
   Loaded: loaded (/lib/systemd/system/prosody.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-04-15 15:19:58 CEST; 1 day 9h ago
     Docs: https://prosody.im/doc
 Main PID: 3572 (lua5.2)
    Tasks: 1 (limit: 4581)
   Memory: 18.4M
   CGroup: /system.slice/prosody.service
           └─3572 lua5.2 /usr/bin/prosody

service jitsi-videobridge2 status
Shows:

● jitsi-videobridge2.service - Jitsi Videobridge
   Loaded: loaded (/lib/systemd/system/jitsi-videobridge2.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-04-15 13:11:15 CEST; 1 day 11h ago
  Process: 1106 ExecStartPost=/bin/bash -c echo $MAINPID > /var/run/jitsi-videobridge/jitsi-videobridge.pid (code=exited
 Main PID: 1105 (java)
    Tasks: 41 (limit: 65000)
   Memory: 276.3M
   CGroup: /system.slice/jitsi-videobridge2.service
           └─1105 java -Xmx3072m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dnet.jav

service jicofo status
Shows:

● jicofo.service - LSB: Jitsi conference Focus
   Loaded: loaded (/etc/init.d/jicofo; generated)
   Active: active (running) since Wed 2020-04-15 15:08:05 CEST; 1 day 9h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 3192 ExecStart=/etc/init.d/jicofo start (code=exited, status=0/SUCCESS)
    Tasks: 107 (limit: 4581)
   Memory: 218.2M
   CGroup: /system.slice/jicofo.service
           └─3200 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dnet.java.sip.communicator.SC_HO

Jibri

This server depends on 1 service: jibri

service jibri status
Shows:

● jibri.service - Jibri Process
   Loaded: loaded (/etc/systemd/system/jibri.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-04-15 13:16:18 CEST; 1 day 11h ago
 Main PID: 749 (java)
    Tasks: 36 (limit: 4581)
   Memory: 471.4M
   CGroup: /system.slice/jibri.service
           └─749 java -Djava.util.logging.config.file=/etc/jitsi/jibri/logging.properties -jar /opt/jitsi/jibri/jibri.jar --config /etc/jitsi/jibri/config.json

Apr 15 13:16:18 jibri systemd[1]: Started Jibri Process.
Apr 15 13:16:20 jibri launch.sh[749]: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
Apr 15 13:16:20 jibri launch.sh[749]: SLF4J: Defaulting to no-operation (NOP) logger implementation
Apr 15 13:16:20 jibri launch.sh[749]: SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Apr 15 13:18:37 jibri launch.sh[749]: Starting ChromeDriver 81.0.4044.69 (6813546031a4bc83f717a2ef7cd4ac6ec1199132-refs/branch-heads/4044@{#776}) on port 26333
Apr 15 13:18:37 jibri launch.sh[749]: Only local connections are allowed.
Apr 15 13:18:37 jibri launch.sh[749]: Please protect ports used by ChromeDriver and related test frameworks to prevent access by malicious code.

Log-files

locations,

Jitsi:
    /var/log/prosody
    /var/log/jitsi
Jibri:
    /var/log/jitsi/jibri

Investigation first part: check logfiles when services are started but idle
To investigate logfiles can be daunting, I suggest following approache(s):
Step 1: Stop all 3 services prosody, jitsi-videobridge2 and jicofo (or single service on jibri),
Step 2: Remove ALL files from the log-directories,
Step 3: Restart the services in order: prosody, jitsi-videobridge2 and jicofo
Wait approx. 1 minute and then Stop all 3 services again(!).

Now, the logfiles are not filling up anymore and they are not very large, which makes a first analysis more comfortable. Now aall lines with INFO messages can be removed to narrow the search even further down.

Investigation second part: check output when initialising/utilising a video conference
If you cannot find a cause for your problem, then a second phase should be considered to investigate more…
Step 1: If an error occurs, try to find the steps to reproduce the error. Do this several times to make sure you you know how to force the error!
Step 2: Stop all 3 services and Remove ALL files from the log-directories (like above),
Step 3: Restart the services in order: prosody, jitsi-videobridge2 and jicofo and rather soon proceed with the steps to force the error,
Step 4: Stop all 3 services again(!).

Now examine the logfiles and focus on the timing around the moment where the error was enforced. Also here I tend to remove all lines with INFO messages to narrow it even further down.

While writing this final document, I recognise that my jitsi-videobridge2 and jicofo are complaining with the same error:

CGroup: /system.slice/jicofo.service
└─3200 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dnet.java.sip.communicator.SC_HO

So that’s all folks, happy hunting! (I’m off… Hunting for more clues about “+HeapDumpOnOutOfMemoryError”), seems I need to peek in Path=/tmp

Cheers, Igor

4 Likes

Hi Woodworker_Life. Thanks for the detailed procedure.
When I execute the script to generate SSL certificates, it jumps to prompt right after enter my email account.

I have not idea why is this happening. Could you help me please?

Thanks!

root@jitsi:/etc/letsencrypt/renewal-hooks/deploy# sh /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
-------------------------------------------------------------------------
This script will:
- Need a working DNS record pointing to this machine(for domain -ejitsi.rata.net)
- Download certbot-auto from https://dl.eff.org to /usr/local/sbin
- Install additional dependencies in order to request Let’s Encrypt certificate
- If running with jetty serving web content, will stop Jitsi Videobridge
- Configure and reload nginx or apache2, whichever is used
- Configure the coturn server to use Let's Encrypt certificate and add required deploy hooks
- Add command in weekly cron job to renew certificates regularly

You need to agree to the ACME server's Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
Enter your email and press [ENTER]: myemail@gmail.com
--2020-04-15 23:11:39--  https://dl.eff.org/certbot-auto
Resolving dl.eff.org (dl.eff.org)... 151.101.192.201, 151.101.128.201, 151.101.64.201, ...
Connecting to dl.eff.org (dl.eff.org)|151.101.192.201|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80073 (78K) [application/octet-stream]
Saving to: ‘certbot-auto’

certbot-auto                     100%[==========================================================>]  78.20K  --.-KB/s    in 0.01s

2020-04-15 23:11:39 (6.87 MB/s) - ‘certbot-auto’ saved [80073/80073]

root@jitsi:

As I said in the beginning of my post: please consider me newbee! :slightly_smiling_face:

What I see is different from my steps is that you call the letsencrypt-script while you are in /etc/letsencrypt/renewal-hooks/deploy… Try:

cd -

(should return you to your root user directory)
and call the script again?.. Hope this works, otherwise we may need some mighty help from the community… :wink:

Thanks for your response.

I followed your suggestion, but the same occurs.
I wonder if letsencrypt blacklisted my domain because of so many requests.

Thanks for your how-to on these installation methods, @Woodworker_Life.

Would you mind posting your docs also in the github wiki on https://github.com/jitsi/jitsi-meet/wiki ? You can create new pages for each how-to and add your pages to the Wiki home page. That would be very helpful for others and help build a more comprehensive documentation.

1 Like

thank you @elgigi for your feedback… To be honest I don’t fee really qualified to post on GitHub, I have never posted anything on GitHub, don’t even have an account. :wink:

First I will observe the feeback here and IF my tutorial does not generate more questions than I can handle, I will consider to upload to GitHub wiki.

Have a great day!
Cheers, Igor

1 Like

It happened to me as well, i generated SSL certificate by hand and placed in appropriated directory.

1 Like

I found that the script only works once with the domain you specified. If you try to run again the script jump directly to prompt.
I hope my experience helps to someone else.

Hi Woodworker_Life, i followed step by step your explanation, still jibri doesn’t work :frowning:
I’m using Ubuntu 16.04, as per Jibri readme. Any idea about problem?

PS: Jitsi works fine

please post the following logs from jibri server

/var/log/jitsi/jibri/log.0.txt
/var/log/jitsi/jibri/browser.0.txt

& jitsi server

/var/log/jitsi/jicofo.log

you can check if you’re domain has hit rate limits here

https://crt.sh

1 Like

Thank you!

I want to share the solution in case anyone is experience the same problem:

If you want to reinstall your server utilizing the same subdomain than before, you must first revoke your letsencrypt certificate running the following command:

certbot revoke --cert-path /etc/letsencrypt/live/subdomain.yourdomain.com/cert.pem

Only then you will be able to run the script located at /usr/share/jitsi-meet/scripts/ succesfully.

:laughing: :pray:

1 Like

Hi @Woodworker_Life ,

Great tutorial !

Allow me to correct a little confusion here. As you have mention on : https://aws1.discourse-cdn.com/business4/uploads/jitsi/original/2X/2/2384271218f011992a18527debd6483a6100f16f.png
you highlighted “recording” and “livestreaming” buttons.

As far as I understand, the livestreaming means that jibri connects to participant event via Youtube data API. But on your tutorial, I think there is no steps to trigger youtube API.

From what I understand by Participant Event is, any participant can initiate livestreaming from their youtube account.

Please correct me if I’m wrong.

Thank you and sincerely,
arivonto

@Woodworker_Life great job!
I’d just suggest to enable ufw only after setting it up, in case you lost connection or similar you could remain trapped out of the server.

Did you even made a monkey proof tutorial for scalable configurations? The GitHub one is confusing me a lot

Hi @arivonto, functionality for recording AND streaming become both available when the implementation is done according the steps I describe. When recording, the resulting mp4 file will be stored on the server (in /srv/recordings). Youtube streaming will also be available and does not need a separate- or additional configuration or setup. When streaming, you will need to enter your youtube stream-id which I did not describe in my post; that is all explained in the youtube-clip that I linked at the end of my post…

Cheers, Igor

1 Like

Hi @RubensRainelli, got your point! I think I’m no longer allowed to edit my post (it seems this forum locks the edit-function when a post is older than 1 day), but it makes sense to do as you suggest indeed.

Thanks, cheers, Igor