Computerwerk Darmstadt e.V.

In neueren Versionen von Jitsi-Meet scheinen einige Veränderungen vorgenommen worden zu sein. Es ist also möglich, dass Teile dieser Anleitung nicht mehr zutreffend sind!

Spezielle Infos für Debugging usw. finden sich im internen Bereich

Die Installation erfolgte über das Jitsi eigene Repository auf Ubuntu 16.04 LTS. Bei neueren Ubuntu und Debian Versionen treten aufgrund des neueren Java 11 leider Fehler auf. Dafür haben wir die folgende Anleitung genutzt die aber nachfolgend auch nochmal wiedergegeben wird https://jitsi.org/downloads/ubuntu-debian-installations-instructions/

Soweit nicht anders erwähnt, braucht ihr für alle Befehle root-Rechte

Für die Nutzung des Jitsi Repository müsst ihr das Paket „apt-transport-https“ und „gpg“ installiert haben. Bei neueren Distributionen ist das schon vorbereitet.

Einrichtung des Repos erfolgt mit:

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 | apt-key add -

Vor dem nächsten Schritt solltet ihr euch überlegen über welche Domain Jitsi betrieben werden soll. Ob die nachfolgenden Subdomains wirklich benötigt werden hängt von der Nutzung eures Systems ab. Wenn alle Komponenten auf einer Maschine laufen wird nur die Hauptdomain benötigt. Wir haben sie einfach alle geschaltet und können so flexibel ausbauen.

In unserem Falle wären die Domains bspw.:

• meet.computerwerk.org → braucht ihr bei der Installation
• auth.meet.computerwerk.org
• conference.meet.computerwerk.org
• focus.meet.computerwerk.org
• jitsi-videobridge.meet.computerwerk.org (und weitere)

Die Domains sollten natürlich auf die IP/die Domain zeigen unter der der Server später erreichbar ist.

Die verwendeten Domains lassen sich nachträglich auch in der Datei /etc/jitsi/meet/<EUREDOMAIN>-config.js anpassen.

apt update #aktualisiert die Paketquellen
apt install jitsi-meet #installiert jitsi-meet und die zugehörigen Abhängigkeiten - ihr werdet nach der Domain gefragt - wählt bei der Abfrage "self-signed-certificate"

Nun ist der Jitsi-Server installiert und sollte sich automatisch im Hintergrund starten (war nicht schwer, oder ;) )

Wir sind aber noch nicht fertig.

Da Jitsi später über eine externe IP erreichbar sein wird, er aber im NAT mit interner IP firmiert, müssen wir ihm das mitteilen. Außerdem verbieten wir der Videobridge die Kommunikation per TCP. Dafür bearbeiten wir die Datei /etc/jitsi/videobridge/sip-communicator.properties und fügen die folgenden Zeilen ein

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=$INTERNEIP
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=$EXTERNEIP
org.jitsi.videobridge.NAT_HARVESTER_LOCAL_ADDRESS=$INTERNEIP
org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS=$EXTERNEIP

Die Werte $INTERNEIP und $EXTERNEIP müsst ihr dabei mit euren IPs ersetzen

Die Installationprozedur hat Nginx auf der genutzen Maschine automatisch eingerichtet. Dabei wurde auch SSL mit einem Self-Signed-Certificate eingerichtet. Dies wollen wir aber gar nicht nutzen. Daher bearbeiten wir die Datei /etc/nginx/sites-enabled/<EUREDOMAIN>.conf

Wir entfernen den ersten Block zwischen „server {“ und der schließenden „}“ in dem sich die Ziele „listen 80;“ befindet. Nun bearbeiten wir den zweiten Block un ändern die Zeile „listen 443“ zu „listen 80“. Die nachfolgenden 6 Zeilen ab „ssl_protocols…“ bis „ssl_certificate…“ entfernen wir (beginnen alle mit ssl bzw eine Zeile lautet add-header…)

Das war es. Nun noch mit „systemctl reload nginx“ den Webserver neu starten.

Unsere Infrastruktur ist durch verschiedene Konfigurationen geschützt. Dazu gehört auch, dass wir ein zentrales SSL-Offloading mit Apache Reverse Proxy betreiben. Wir mussten also neben dem Betrieb des Servers im NAT zudem einen Workaround für das SSL-Offloading finden.

Dafür wurde im Apache ein VirtualHost eingerichtet der u.a. folgende Settings enthält:

        RewriteEngine on

        ProxyRequests Off
        ProxyPreserveHost On
        ProxyErrorOverride    On

        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteRule /(.*)           ws://$LOKALEIP/$1 [P,L]
        RewriteCond %{HTTP:Upgrade} !=websocket [NC]
        RewriteRule /(.*)           http://$LOKALEIP/$1 [P,L]

        ProxyPass / http://$LOKALEIP/
        ProxyPassReverse / http://$LOKALEIP/

Die Werte $INTERNEIP und $EXTERNEIP müsst ihr dabei mit euren IPs ersetzen

Leider kann Jitsi beim Broadcasten nicht den Weg über den Reverse Proxy verwenden. Daher muss in der Firewall die Ports 10000 bis 20000 UDP für den Jitsi-Server bzw. die Videobridge freigegeben werden.

Das wars, nun sollte der Server laufen

Jitsi ist in Java geschrieben und vieles in diesem Code direkt implementiert. Es ist daher nur sehr eingeschränkt möglich die Oberfläche zu verändern ohne in den Javacode einzusteigen und die App selbst zu kompilieren.

An einigen Stellen bietet das System allerdings die Möglichkeit von Änderungen

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

/usr/share/jitsi-meet/images/watermark.png

/usr/share/jitsi-meet/css/all.css

Etwas umfangreicherer Workaround findet sich auch hier: https://community.jitsi.org/t/change-welcome-page-text-after-quick-install/15279

Deutsche Sprachdatei: /usr/share/jitsi-meet/lang/main-de.json