Jitsi Meet Server - Stable-latest

Diese Installation habe ich auf einem Ubuntu 20.04 gemacht.

Nachdem meine Stable-latest Version nicht mehr richtig ging, habe ich mich entschlossen den ganzen Server neu aufzusetzen.

Voraussetzungen

Ein ADSL-Router mit Portforwarding
Ich möchte mein Heimnetz schützen und habe deswegen natürlich einen normalen ADSL-Router mit NAT-Funktion, durch den ich gezielte Löcher bohre.
Ein x86 PC mit Ubuntu 20.04
Es geht bestimmt auch mit anderen Systemen aber meine Anleitung bezieht sich auf dieses System.
Ein Raspberry Pi scheidet aus zwei Gründen aus:
1. Die Jitsi Meet Server Debian Installationspakete gibt es nur für x86
2. Der Raspberry Pi 3 hat sogar als NAT-Router zu wenig Dampf
Mindestens wenige Minuten Zeit
- wenn alles gut geht. Ansonsten dauert es sehr schnell länger.
Abgeschaltetes IP6
Ich kann es nicht exakt sagen, aber die Schnellinstallation ging bei mir nur mit IP4.

Installation

Eine Anleitung dazu bietet Jitsi selber. Ich habe nur den Private Port hinzu gefügt.

Als erstes habe ich meine vorhandenen Let's Encrypt Zertifikate installiert:

cd /
sudo tar -xhzvf letsencrypt.tar.gz

Eingepackt habe ich sie übrigens mit diesem Kommando: sudo tar -czvf letsencrypt.tar.gz /etc/letsencrypt

Dann fehlten noch vier Komponenen: sudo apt install apt-transport-https curl gnupg2 nginx-full

Die ersten Schritte sind genau nach Anleitung.

sudo apt-add-repository universe
sudo apt update

curl https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo 'deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list > /dev/null
sudo apt update

Weiter geht es mit der Installation des Paketes. sudo apt install jitsi-meet

Hierbei ist folgendes zu beachten:

Wird eine IP-Adresse als hostname eingegeben, so muss ein Self-Signed-Certificate verwendet werden
Ein Let's Encrypt Zertifikat verlangt einen Namen mit Punkten für Domain und Land.

In meinem Fall hatte ich bereits Let's Encrypt Zertifikate, die ich bei der Installation verwendet habe.

Wenn nach dem SSL Schlüssel gefragt wird, ist das "privkey.pem" anzugeben. /etc/letsencrypt/live/<servername>/privkey.pem

Wenn nach dem SSL Zertifikat gefragt wird, ist das "fullchain.pem" anzugeben. /etc/letsencrypt/live/<servername>/fullchain.pem

Private Port

Im Sinne meines Bedarfs an Datenschutz möchte ich natürlich nicht den Standard Port für HTTPS (443) verwenden. Dafür sind diese Dateien anzupassen:

nano /etc/jitsi/meet/<servername>-config.jsbosh: '//<servername>:<private port>/http-bind',

Hier ist die Zeile mit der Variablen STUN_MAPPING_HARVESTER_ADDRESSES zu entfernen und die neuen Zeilen sind einzufügen:

nano /etc/jitsi/videobridge/sip-communicator.propertiesorg.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<Lokale IP-Adresse>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<Externe IP-Adresse>
org.ice4j.ipv6.DISABLED=true
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=<private port>+2

Für die Freigabe von Fenstern ist hier auf den freigegebenen UDP-Port umzustellen sudo nano /etc/jitsi/videobridge/jvb.confdomain = "<servername>:<private port>+2"

Dann muss noch der NGINX Server angepasst werden

sudo nano /etc/nginx/sites-available/<servername>.confserver {
...
#    listen [::]:80;
...
server {
#    listen 443 ssl;
    listen <private port> ssl;
#    listen [::]:443 ssl;

Und auch der TURN Server muss angepasst werden

sudo nano /usr/share/jitsi-meet-turnserver/jitsi-meet.confserver {
#    listen 443 ssl;
    listen <private port> ssl;
#    listen [::]:443 ssl;

Im NAT-Router sind der <private port> für TCP und der <private port>+2 für UDP aus dem Internet weiter zu leiten zum Jitsi Meet Server. Der UDP-Port ist nicht an den Abstand (+2) gebunden, ich finde es aber praktisch.

Tja und dann haben wir im Privatbereich noch das Problem der dynamischen IP Adresse.
Also einmal am Tag wird die Internet Verbindung unterbrochen und unser DSL-Router bekommt unter Umständen eine neue externe IP Adresse, die in der Konfiguration anzugeben ist. Was nun?

Das Problem der Zuordnung eines festen Namens zu dieser wechselnden Adresse wird durch viele Anbieter gelöst. Darauf will ich hier nicht eingehen.

Aber was mache ich in den sip-communicator.properties? Dort wird eine IP-Adresse und kein Name gefordert. Auch das läßt sich unter Linux elegant lösen.
Ich gehe davon aus, daß:

Der Jitsi Meet Server läuft nicht durch, sondern wird immer wieder neu gestartet.
Der Wechsel der IP-Adresse erfolgt außerhalb der Laufzeit des Jitsi Meet Servers.

Unter diesen Umständen genügt es die aktuelle, externe IP-Adresse beim Hochlauf des Jitsi Meet Servers zu setzen. Das mache ich hiermit:

sudo nano /etc/init.d/updateextern#!/bin/bash

### BEGIN INIT INFO
# Provides:          updateextern
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Should-Start:      $local_fs slapd $named
# Should-Stop:       $local_fs slapd
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Update the Jitsi Videobridge
# Description:       Update the configured Jitsi Videobridge external IP Address to the current value
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

. /lib/lsb/init-functions

NAME=updateextern
DESC="Update the Jitsi Videobridge"

NATROUTER_PID="/var/run/updateextern.pid"

updateaddress()
{
	# Compare the current external IP adress with the configured value
	SETIP=`cat /etc/jitsi/videobridge/sip-communicator.properties | grep NAT_HARVESTER_PUBLIC_ADDRESS | sed -e "s#.*=##g"`
	CURRENTIP=`dig @resolver1.opendns.com A myip.opendns.com +short -4`
	if [ "$SETIP" != "$CURRENTIP" ]; then
	    # Set the new value and reboot
	    REMAIN=`cat /etc/jitsi/videobridge/sip-communicator.properties | grep -v NAT_HARVESTER_PUBLIC_ADDRESS`
	    PREFIX=`cat /etc/jitsi/videobridge/sip-communicator.properties | grep NAT_HARVESTER_PUBLIC_ADDRESS | sed -e 's#=.*#=#g'`
	    NEW=`echo -e "$REMAIN\n$PREFIX$CURRENTIP"`
	    echo "$NEW" > /etc/jitsi/videobridge/sip-communicator.properties
	    sleep 2
	    reboot
	fi
}

case "$1" in
	start)
	        log_daemon_msg "Starting $DESC" "$NAME"
	        start-stop-daemon --start --quiet --pidfile "$NATROUTER_PID"
	        updateaddress
	        sleep 2
	        ;;
	stop)
	        log_daemon_msg "Stopping $DESC" "$NAME"
	        start-stop-daemon --stop --quiet --pidfile "$NATROUTER_PID"
	        log_end_msg $?
	        rm -f "$NATROUTER_PID"
	        ;;
	restart | force-reload)
	        $0 stop
	        sleep 2
	        $0 start
	        if [ "$?" != "0" ]; then
	                exit 1
	        fi
	        ;;
	status)
	        echo -n "Status of $DESC: "
	        check_status -v
	        exit "$?"
	        ;;
	*)
	        echo "Usage: $0 {start|stop|restart|force-reload|status}"
	        exit 1 
esac

exit 0sudo chmod +x /etc/init.d/updateextern
sudo update-rc.d updateextern defaults

Mit diesen Kommandos läuft die Funktion updateaddress() einmal beim Hochlauf des PCs. Sollte eine Differenz vorliegen, wird die neue Adresse eingetragen und der PC neu gebootet.

Soll der PC durchlaufen, so muss der Inhalt der Funktion updateaddress() per Root CronJob einmal am Tag durchlaufen werden. Auch dafür gibt es viele Anleitungen im Internet.

So, das war's. Wenn der PC nun neu gestartet wird, so sollte alles laufen. Für einen Test gebt ihr den Link https://<dynamic name> als Adresse in einem Mozilla Firefox oder Chrome Browser ein und freut euch am Ergebnis.

Wie immer bin ich neugierig, was bei der Reproduktion so alles auffällt. Ich würde mich also über eine kurze eMail sehr freuen.