DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx

Jitsi Logo

Videokonferenzen werden heutzutage immer wichtiger. Im geschäftlichen Umfeld kommen hier meist proprietäre Lösungen wie z.B. Skype zum Einsatz. In Sachen Datenschutz und Privatsphäre sind diese Lösungen natürlich bedenklich.

Die bessere Alternative kann hier Jitsi Meet sein. Dies ist eine quelloffene Software, mit der Videokonferenzen mit mehreren Teilnehmern durchgeführt werden können.

Der folgende Artikel zeigt die Installation und Konfiguration von Jitsi Meet unter Ubuntu Server mit nginx als Webserver. Ebenso kommt coturn als eigener TURN-/STUN-Server zum Einsatz.

Update-Historie (letztes Update: 02.05.2020)
  • 31.08.2020:
    • Update vHost für Jitsi Meet.
  • 02.05.2020:
    • Einbindung eines eigenen coturn-Servers verbessert (useStunTurn).
    • Hinweis zum Deaktivieren der Verbindungen zu externen Diensten ergänzt.
  • 05.04.2020:
    • Artikel nochmals auf die aktuellste Jitsi Meet Version angepasst.
    • coturn wird nun als TURN-/STUN-Server für Jitsi Meet integriert.
  • 03.04.2020:
    • Artikel überarbeitet, da sich nach dem letzten Update von Jitsi Meet einiges geändert hat.
  • 28.03.2020:
    • Weitere Hinweise zur Verwendung eines eigenen STUN-Servers (coturn) hinzugefügt.

Voraussetzungen/Ziele

Zum Thema Jitsi Meet gibt es bereits unzählige Tutorials im Netz. Diese beziehen sich aber meist nur auf die Standard-Installation und es wird meist auch nicht explizit auf die Webserver-Konfiguration eingegangen. Das Augenmerk auf die (sichere) Webserver-Konfiguration ist meiner Meinung allerdings sehr wichtig, v.a. wenn auf dem Server bereits andere Anwendungen gehostet werden.

Darüber hinaus schlägt die Installation unter Ubuntu Server 18.04 u.U. manchmal fehl. Hier gilt es dann einige Besonderheiten zu beachten.

Dabei kommen folgende Programm-Versionen zum Einsatz:

  • Ubuntu Server 18.04 LTS („Bionic Beaver“).
  • nginx 1.17.9 (aktuelle Mainline-Version).
  • coturn 4.5.0.7.

Dieses Tutorial konzentriert sich dabei v.a. auf Jitsi Meet. Eine komplette Beschreibung der Webserver-Konfiguration (nginx, Let’s Encrypt/acme.sh) würde sicherlich den Rahmen des Artikel sprengen.

Wichtig: nginx muss vor der Installation von Jitsi Meet bereits auf dem System vorhanden sein, da das Jitsi-Setup darauf aufbaut und virtuelle Hosts anlegt.

Ich gehe im folgenden davon aus, dass auf dem System nginx bereits installiert und eingerichtet ist. Ebenfalls sollte alles vorbereitet sein, dass TLS-Zertifikate über Let’s Encrypt ausgestellt werden können.

Wie eine entsprechende Konfiguration (nginx/Let’s Encrypt) aussehen kann wird in folgenden Artikel näher beschrieben:

Ebenso wird eine bereits laufende Instanz von coturn (TURN-/STUN-Server) vorausgesetzt. Die dies umgesetzt werden kann, ist im Artikel Nextcloud Talk mit eigenem TURN-Server (coturn) beschrieben.

Im Rahmen des Tutorials nutze ich folgende beispielhafte Domains:

  • meet.meinedomain.de für die Jitsi Meet Installation.
  • turn.meinedomain.de für die coturn-Instanz.

Systemvoraussetzungen

Jitsi Meet hat moderate Systemvoraussetzungen, was CPU/RAM angeht. Logischerweise sind die Anforderungen bzgl. der Bandbreite (Up- bzw. Download) für eine Videokonferenz-Lösung recht hoch. Dies hängt allerdings stark von der erwarteten Nutzung (= Anzahl der parallel zugreifenden Teilnehmer) des Jitsi Meet Servers ab.
Trotzdem sollte man sich an einem privaten Internet-Anschluss nicht all zu viele Hoffnungen machen. Auch bei einer guten Bandbreite des Internet-Anschlusses wird man hier bei einer selbstgehosteten Lösung in den eigenen vier Wänden nur Konferenzen mit wenigen Teilnehmern durchführen können. Im Allgemeinen ist daher die Empfehlung, Jitsi Meet auf einem eigenen Root-Server zu betreiben. Aus eigener Erfahrung kann ich hier einen Server von Netcup (Affiliate-Link) empfehlen.

Vor der Installation zu beachten

Jitsi Meet besteht aus einer Reihe von Komponenten, die im Rahmen des Setups installiert werden.

Wenn auf dem Server bereits Teile dieser Komponenten installiert sind, besteht die Gefahr, dass bereits laufende Systeme unbrauchbar werden, da Jitsi Meet einfach die bestehenden Komponenten/Konfiguration überschreibt.

Dies betrifft zum einen coturn, als auch Prosody.
Die Beschreibungen in diesem Artikel sorgen dafür, dass ein vorhandener coturn Server nicht überschrieben wird.

Allerdings sollte das Jitsi Meet Setup nicht ausgeführt werden, wenn bereits ein Prosody/XMPP Server auf dem System betrieben wird.

Vorbereitungen

Nun kann es auch schon an die Installation gehen.

Betriebssystem-Updates

Vor der eigentlichen Installation wird das System zunächst auf den neusten Stand gebracht:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove 
reboot

Anpassungen nginx

Wichtig: nginx ist meistens so konfiguriert, dass die virtuellen Hosts unter /etc/nginx/conf.d geladen werden. Das Setup von Jitsi Meet geht allerdings davon aus, dass die virtuellen Hosts unter /etc/nginx/sites-available bzw. /etc/nginx/sites-enabled zu finden sind. Daher müssen diese Verzeichnisse manuell angelegt werden, falls diese noch nicht vorhanden sind (dies betrifft darüber hinaus auch noch ein drittes Verzeichnis):

mkdir -p /etc/nginx/sites-available
mkdir -p /etc/nginx/sites-enabled
mkdir -p /etc/nginx/modules-enabled

Wird dieser Schritt nicht ausgeführt, schlägt das Setup von Jitsi Meet später fehl!

Domain/TLS-Zertifikate

Wie bereits erwähnt, nutzen wir für den Artikel die fiktive (Sub-)Domain meet.meinedomain.de.

Für diese Domain sollten vor dem Jitsi-Setup bereits Zertifikate über Let’s Encrypt beantragt werden. Folgende Artikel sollten dazu einen guten Anhaltspunkt geben:

Die folgende Konfiguration wird RSA- und ECDSA-Zertifikate (Hybrid-Betrieb) mit TLSv1.2/TLSv1.3 nutzen.

Auflösung der Domain auf localhost

Auf dem Server, auf dem Jitsi Meet installiert werden soll, muss die verwendete Domain auf localhost auflösen. Dies wird in der Hosts-Datei konfiguriert:

nano /etc/hosts

Ganz unten wird nun folgender Eintrag hinzugefügt:

127.0.0.1 meet.meinedomain.de

Installation Jitsi Meet

Als nächstes kann es an die eigentliche Installation von Jitsi Meet gehen.

Jitsi Meet – Setup

Da das Programm (noch) nicht in den offiziellen Ubuntu Paketquellen enthalten ist, müssen wir das Repository zunächst einbinden.

Dazu wird als erstes der Repository-Key im System importiert:

wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -

Anschließend kann das Repository eingebunden werden:

echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list

Nun werden die Paketquellen noch aktualisiert:

apt update

Es folgt die eigentliche Installation.
Wichtig ist hierbei die Angabe von no-install-recommends, da ansonsten u.a. die Konfiguration von coturn überschrieben wird. 

apt install --no-install-recommends jitsi-meet

Während der Installation wird man zuerst nach der Domain gefragt, unter der Jitsi Meet gehostet werden soll. Dies ist die Domain, für das vorher schon das TLS-Zertifikat ausgestellt wurde – in diesem Beispiel also meet.meinedomain.de.

Jitsi Meet Setup: Eingabe der Domain

Jitsi Meet Setup: Eingabe der Domain

Als nächstes wird noch nach dem Zertifikat gefragt: Hier muss die zweite Option gewählt werden (I want to use my own certificate), da wir die Zertifikate selbst verwalten wollen (siehe oben).

Jitsi Meet Setup: Verwendung eigener Zertifikate

Jitsi Meet Setup: Verwendung eigener Zertifikate

Nun wird man noch nach dem Speicherort der Zertifikats-Dateien gefragt. Diese beiden Dialoge (einmal für die *.key und einmal für die *crt-Datei) kann einfach mit OK bestätigt werden. Die Zertifikate werden im Anschluss manuell im virtuellen Host von nginx hinzugefügt.

Jitsi Meet Setup: Pfad zu den Zertifikats-Dateien

Jitsi Meet Setup: Verwendung eigener Zertifikate

Das Setup sollte anschließend ohne Probleme durchlaufen.

Jitsi Meet – Anpassen des virtuellen Hosts (nginx)

Das Setup hat nun im Verzeichnis /etc/nginx/sites-available einen neuen virtuellen Host erstellt und einen symbolischen Link in /etc/nginx/sites-enabled hinzugefügt. Da wir an dieser Stelle die Verzeichnisse sites-availabe und sites-enabled nicht verwenden, wird die Datei hier entfernt und in das passende Verzeichnis verschoben:

rm /etc/nginx/sites-enabled/meet.meinedomain.de.conf
mv /etc/nginx/sites-available/meet.meinedomain.de.conf /etc/nginx/conf.d/meet.meinedomain.de.conf

Den Webserver noch nicht neu starten, erst bedarf es noch Anpassungen am vHost für Jitsi Meet.

nano /etc/nginx/conf.d/meet.meinedomain.de.conf

Diese Datei wird nun folgendermaßen erweitert:

server_names_hash_bucket_size 64;

#server {
#    listen 80;
#    server_name meet.meinedomain.de;
#    return 301 https://$host$request_uri;
#}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name meet.meinedomain.de;

    #
    # SSL configuration
    # 

    # RSA certificates
    ssl_certificate /etc/letsencrypt/meet.meinedomain.de/rsa/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/meet.meinedomain.de/rsa/key.pem;
    # ECC certificates
    ssl_certificate /etc/letsencrypt/meet.meinedomain.de/ecc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/meet.meinedomain.de/ecc/key.pem;

    # This should be ca.pem (certificate with the additional intermediate certifica$
    # See here: https://certbot.eff.org/docs/using.html
    # ECC
    ssl_trusted_certificate /etc/letsencrypt/meet.meinedomain.de/ecc/ca.pem;

    # SSL stapling has to be done seperately, becuase it will not work with self signed certs
    # OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    # Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
    ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

    # Not using TLSv1 will break:
    # Android <= 4.4.40 IE <= 10 IE mobile <=10
    # Removing TLSv1.1 breaks nothing else!
    ssl_protocols TLSv1.2 TLSv1.3;

    # SSL ciphers: RSA + ECDSA
    # Two certificate types (ECDSA, RSA) are needed.
    ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';
    
    # Use multiple curves.
    ssl_ecdh_curve secp521r1:secp384r1;

    # Server should determine the ciphers, not the client
    ssl_prefer_server_ciphers on;

    # Add your DNS resolver here
    resolver 192.168.178.1;

    # SSL session handling
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;

    # 
    # Headers
    #

    # HSTS (ngx_http_headers_module is required) In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header X-Robots-Tag none always;
    add_header X-Download-Options noopen always;
    add_header X-Permitted-Cross-Domain-Policies none always;
    add_header Referrer-Policy no-referrer always;
    #add_header X-Frame-Options "SAMEORIGIN" always;

    # Remove X-Powered-By, which is an information leak
    fastcgi_hide_header X-Powered-By;


    root /usr/share/jitsi-meet;

    # ssi on with javascript for multidomain variables in config.js
    ssi on;
    ssi_types application/x-javascript application/javascript;

    index index.html index.htm;
    error_page 404 /static/404.html;

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

    location = /config.js {
        alias /etc/jitsi/meet/meet.meinedomain.de-config.js;
    }

    location = /external_api.js {
        alias /usr/share/jitsi-meet/libs/external_api.min.js;
    }

    #ensure all static content can always be found first
    location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
    {
        add_header 'Access-Control-Allow-Origin' '*';
        alias /usr/share/jitsi-meet/$1/$2;
    }

    # BOSH
    location = /http-bind {
        proxy_pass      http://localhost:5280/http-bind;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
    }

    # xmpp websockets
    location = /xmpp-websocket {
        proxy_pass http://127.0.0.1:5280/xmpp-websocket?prefix=$prefix&$args;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        tcp_nodelay on;
    }

    location ~ ^/([^/?&:'"]+)$ {
        try_files $uri @root_path;
    }

    location @root_path {
        rewrite ^/(.*)$ / break;
    }

    location ~ ^/([^/?&:'"]+)/config.js$
    {
        set $subdomain "$1.";
        set $subdir "$1/";

        alias /etc/jitsi/meet/meet.decatec-it.de-config.js;
    }

    #Anything that didn't match above, and isn't a real file, assume it's a room name and redirect to /
    location ~ ^/([^/?&:'"]+)/(.*)$ {
        set $subdomain "$1.";
        set $subdir "$1/";
        rewrite ^/([^/?&:'"]+)/(.*)$ /$2;
    }

    # BOSH for subdomains
    location ~ ^/([^/?&:'"]+)/http-bind {
        set $subdomain "$1.";
        set $subdir "$1/";
        set $prefix "$1";

        rewrite ^/(.*)$ /http-bind;
    }

    # websockets for subdomains
    location ~ ^/([^/?&:'"]+)/xmpp-websocket {
        set $subdomain "$1.";
        set $subdir "$1/";
        set $prefix "$1";

        rewrite ^/(.*)$ /xmpp-websocket;
    }
}

Erklärungen zu den einzelnen Änderungen:

  • Zunächst wird der virtuelle Host für HTTP (Port 80) deaktiviert/auskommentiert. Dieser wird nicht benötigt, da dieser schon in einer anderen Datei vorhanden ist (sonst hätte ja die Erzeugung der TLS-Zertifikate über Let’s Encrypt vorher nicht geklappt).
  • Es folgen die Einstellungen für SSL. Die vom Jitsi Meet Setup eingefügten Zeilen wurden hier wieder auskommentiert und durch eigene optimierte Anweisungen ersetzt (RSA- und ECDSA-Zertifikate im Hybrid-Betrieb).
  • Wichtig ist hier noch die Angabe eines (DNS-)Resolvers (resolver 192.168.178.1). Hier ist die IP-Adresse eines DNS-Servers anzugeben (in diesem Beispiel die IP-Adresse des Routers, da dieser als DNS-Server fungiert).
  • Anschließend werden noch Header gesetzt, die für eine sichere Webserver-Konfiguration empfohlen sind.
  • Weiter unten wurde noch ein weiterer location-Block hinzugefügt. Dieser sorgt dafür, dass die externe API von Jitsi Meet verfügbar ist. Dies wird zur Nutzung der Desktop-Clients/mobilen Apps von Jitsi Meet benötigt.

Nun wird der Webserver neu gestartet:

service nginx restart

Zum Schluss müssen ein paar benötigte Ports in der Firewall freigeschaltet werden (in diesem Beispiel nutze ich die Firewall ufw):

ufw allow http
ufw allow https
ufw allow in 10000/udp

Falls eine andere Firewall genutzt wird, ist diese entsprechend zu konfigurieren. Denkt auch daran, dass das Port-Forwarding ggf. auch im Router konfiguriert werden muss (Ports 80, 443, 4443, Protokoll: TCP und Port 10000, Protokoll: UDP).

Diese Ports müssen übrigens auch bei den Clients geöffnet sein (nur für ausgehenden Traffic!).

Konfiguration Jitsi Meet

Nach der Installation müssen noch einige Dinge an der Installation angepasst werden.

coturn als TURN-/STUN-Server

Jitsi Meet benötigt für einen stabilen Betrieb sowohl einen TURN-Server, als auch STUN-Server. Dies ist eine Technologie, die Verbindungen durch Router/Firewalls ermöglicht.

Als TURN-/STUN-Server nutze ich hier die quelloffene Implementierung coturn. Wie ein coturn-Server aufgesetzt werden kann, wurde bereits im Artikel Nextcloud Talk mit eigenem TURN-Server (coturn) beleuchtet.

Zunächst hinterlegen wir die Daten für TURN:

nano /etc/prosody/conf.d/meet.meinedomain.de.cfg.lua

Hier wird ziemlich weit oben der zu verwendende TURN-Server angegeben. Diese Konfiguration wird nun so abgeändert, dass die eigene coturn-Instanz genutzt wird:

turncredentials_secret = "my-secret";

turncredentials = {
  { type = "stun", host = "turn.meinedomain.de", port = "5349" },
  { type = "turn", host = "turn.meinedomain.de", port = "5349", transport = "udp" },
  { type = "turns", host = "turn.meinedomain.de", port = "5349", transport = "tcp" }
};

Wichtig ist hier v.a. das sog. „Secret“, als auch die zu nutzenden Ports. Diese Konfiguration liegt jedoch nicht bei Jitsi Meet, sondern bei coturn selbst. Die Konfiguration von coturn befindet sich dabei hier: /etc/turnserver.conf (tls-listening-port und static-auth-secret).

Für STUN nutzt Jitsi in der Standard-Konfiguration einen eigenen Server (meet-jit-si-turnrelay.jitsi.net:443). Hier können aber auch beliebige andere STUN-Server genutzt werden.

Dazu wird einfach die entsprechende Konfiguration geöffnet:

nano /etc/jitsi/meet/meet.meinedomain.de-config.js

Hier sucht man nun nach der Stelle, an der die STUN-Server hinterlegt sind:

stunServers: [
   { urls: 'meet-jit-si-turnrelay.jitsi.net:443' }
],

Hier können nun andere STUN-Server hinterlegt werden. Eine Liste mit öffentlichen STUN-Servern findet man z.B. hier.

Wir nutzen hier allerdings ebenfalls die eigene coturn-Instanz:

stunServers: [
            { urls: 'stun:stun.meinedomain.de:5349' }
        ],

Damit nur noch der eigene TURN-/STUN-Server genutzt wird, sind noch zwei Variablen (useStunTurn) in dieser Konfigurations-Datei zu ändern:

useStunTurn: true,
# ...
p2p: {
   # ...
   useStunTurn: true,
   # ...

Nun werden alle Dienste nochmal neu gestartet, damit die Änderungen übernommen werden:

service prosody restart
service jicofo restart
service jitsi-videobridge2 restart

Test des eigenen STUN-Servers: Um den eigenen STUN-Server zu testen, kann diese Seite gnutzt werden. Unter STUN or TURN URI wir dann folgendes eingegeben: stun:stun.meinedomain.de:5349

Nach einem Klick auf Gather candidates sollte das Ergebnis dann in etwa so aussehen:

Ergebnisse des STUN-Server Tests

Ergebnisse des STUN-Server Tests

Wichtig sind dabei, dass die Einträge vom Typ „srflx“ angezeigt werden.

Öffentlichen Zugang unterbinden („Secure Domain“)

Jitsi Meet ist nun so konfiguriert, dass jeder, der die URL des Servers kennt, beliebig viele Konferenz-Räume erstellen kann. Dies ist u.U. nicht gewünscht, da man den Server z.B. nur privat verwenden möchte. In diesem Fall kann man Jitsi Meet so konfigurieren, dass neue Konferenz-Räume nur mit einem Benutzernamen und Passwort erstellt werden können.

Wer seine Instanz öffentlich betreiben möchte, muss die folgenden Schritt nicht ausführen.

Dazu ist zunächst eine Anpassungen in folgender Datei nötig:

nano /etc/prosody/conf.avail/meet.meinedomain.de.cfg.lua

Hier werden sog. virtuelle Hosts definiert (nicht zu verwechseln mit den virtuellen Hosts von nginx). Der erste virtuelle Host wird nun so eingestellt, dass eine Authentifizierung erforderlich ist:

VirtualHost "meet.meinedomain.de"
    authentication = "internal_plain"

Am Ende der Datei wird dann ein weiterer virtueller Host hinzugefügt:

VirtualHost "guest.meet.meinedomain.de"
    authentication = "anonymous"
    c2s_require_encryption = false

Als nächstes wird der neue virtuelle Host der Jitsi Meet Installation bekannt gemacht:

nano /etc/jitsi/meet/meet.meinedomain.de-config.js

Unter der Angabe der eigentlichen Domain wird nun die Domain des zuvor angelegten virtuellen Hosts als „anonyme Domain“ hinterlegt:

hosts: {
        // XMPP domain.
        domain: 'meet.meinedomain.de',

        // When using authentication, domain for guest users.
        anonymousdomain: 'guest.meet.meinedomain.de',

Nun muss noch eine weitere Datei bearbeitet werden:

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

Hier fügen wir einfach nur eine Zeile ein:

org.jitsi.jicofo.auth.URL=XMPP:meet.meinedomain.de

Nun folgt noch ein wichtiger Punkt: Das Hinzufügen von Benutzername und Passwort zum Erstellen neuer Konferenz-Räume. Dazu einfach folgenden Befehl direkt in die Kommandozeile eingeben:

prosodyctl register JitsiAdmin meet.meinedomain.de 'mEinPAssw0rt'

JitsiAdmin ist in diesem Beispiel der Benutzername, mEinPAssw0rt das dazugehörige Passwort.

Nach den Änderungen an der Konfiguration von Jitsi Meet sind nun noch die entsprechenden Services neu zu starten:

service prosody restart
service jicofo restart
service jitsi-videobridge2 restart

Verbindungen zu externen Diensten verhindern

Jitsi Meet nutzt einige externe Dienste, wie z.B. Gravatar zum Anzeigen von Benutzer-Icons, wenn die User eine E-Mail-Adresse in den Einstellungen hinterlegt haben und einen Gravatar-Account haben.
Aus Sicht des Datenschutzes ist dies natürlich bedenklich. Wer also auf etwas Komfort verzichten kann, dafür aber Wert auf Datenschutz legt, kann diese Verbindungen zu externen Diensten in Jitsi Meet deaktivieren.

Die Einstellung dazu kann in folgender Datei gesetzt werden:

nano /etc/jitsi/meet/meet.meinedomain.de-config.js

Hier ändern wir nun die entsprechende Variable:

// If third party requests are disabled, no other server will be contacted.
// This means avatars will be locally generated and callstats integration
// will not function.
disableThirdPartyRequests: true,

Zum Übernehmen der Änderungen werden alle Dienste noch einmal neu gestartet:

service prosody restart
service jicofo restart
service jitsi-videobridge2 restart

Nutzung von Jitsi Meet

Die eigene Instanz kann nun einfach im Browser genutzt werden: https://meet.meinedomain.de.

Hinweis: Es gibt momentan wohl noch kleinere Probleme mit neueren Versionen von Firefox. Daher wird offiziell die Verwendung von Chrome/Chromium empfohlen.

Jitsi Meet im Browser

Jitsi Meet im Browser

Als erstes sollte eine Blick in die Einstellungen geworfen werden (Zahnrad oben rechts).
Unter Profil kann ein Name und eine E-Mail-Adresse hinterlegt werden. Der Name wird dann in den Konferenzen angezeigt. An Hand der E-Mail-Adresse wird versucht, per Gravatar ein Avatar für den Benutzer anzuzeigen.

Einstellungen Jitsi Meet

Einstellungen Jitsi Meet

Ebenso kann hier die Sprache der Oberfläche angepasst werden. Nach einem Klick auf OK werden die Einstellungen gespeichert.

Ein Konferenzraum kann nun durch Eingabe des Names für das Meeting und einen Klick auf Los gestartet werden. Der Browser fragt dann, ob man Zugriff auf Mikrofon/Kamera erlauben möchte. Dies sollte man bestätigen, ansonsten macht es ja für Video-Konferenzen wenig Sinn.

Der Konferenz-Raum wird dann noch nicht sofort erstellt, sondern es erscheint eine Meldung mit der Frage nach dem Organisator (dieser Schritt belibt aus, wenn ihr nicht die „Secure Domain“ konfiguriert habt, s.o.):

Jitsi Meet fragt nach dem Organisator

Jitsi Meet fragt nach dem Organisator

Erst nach einem Klick auf „Ich bin der Organisator“ und der Eingabe von Benutzername und Passwort, welches wir weiter oben konfiguriert haben, wird der Raum eröffnet.

Nun präsentiert sich Jitsi Meet mit einer aufgeräumten Oberfläche. Der folgende Screenshot zeigt dabei alle wichtigen Elemente.

Die Oberfläche von Jitsi Meet

Die Oberfläche von Jitsi Meet

Damit andere Leute nun an der Konferenz teilnehmen können, wird einfach der Link auf die Konferenz benötigt (Schaltfläche unten rechts). Ein konkreter Link könnte dann so aussehen: https://meet.meinedomain.de/MeinMeeting

Hier kann auch gleich ein Passwort für die Konferenz eingetragen werden, damit nicht jeder anonyme Benutzer der Konferenz beitreten kann.

Die Benutzung via Browser stellt vermutlich die einfachste Möglichkeit dar. Allerdings gibt es auch Clients für die unterschiedlichsten Plattformen, siehe Jitsi Download-Seite.

Hinweise für Remote Control: Für die Fernsteuerung von Rechnern (ähnlich Teamviewer), muss ein spezieller Desktop-Client („Jitsi Meet Electron“) auf dem fernzusteuernden Rechner genutzt werden. Dieser kann bei GitHub herunter geladen werden. Der Teilnehmer, der die Bedienung remote übernehmen möchte, kann allerdings auch per Browser an der Konferenz teilnehmen.

Fazit

Die eigene Videokonferenz-Lösung aufzusetzen ist mit Jitsi Meet gar nicht so schwer und innerhalb von kürzester Zeit erledigt. Lediglich die individuellen Anpassungen/Absicherungen gehen ein wenig mehr ins Detail.

Man bekommt dafür eine Lösung für Videokonferenzen, die aus Sicht von Privatsphäre und Datenschutz um einiges besser ist als proprietäre Konferenz-Software eines Unternehmens.

Wie steht es bei euch? Nutzt ihr regelmäßig Audio-/Video-Konferenzen? Habt ihr vielleicht schon eure eigene Jitsi Meet Instanz aufgesetzt? Was sind eure Erfahrungen?
Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

, , , , , , , , , , , , , ,

Kommentare: 114

  • fred sagt:

    Hi, very nice guide. Especially the security settings for nginx. I am a bit puzzled by this line:

    >> HSTS (ngx_http_headers_module is required)

    I checked on https://securityheaders.com and my website did not provide HSTS protection, even though it provides an index.html page (like in the setup above).

    It is not installed available /nginx/modules_installed, I think there a no modules provided at all (Debian 10 nginx installed from ADB-package manager).

    Do I have to compile nginx myself to get this working, or is there another way?

    • Jan sagt:

      Hi,

      frist of all, try to call your site in a browser with activated developer console (F12). Check, if the HSTS header is sent twice. If it is sent twice, it gets ignored by these checks. In this case, try to find out where it is set a second time and remove this configuration.

      Best regards,
      Jan

      • fred sagt:

        Hi I only found this info under ->network->mysite.com

        content-encoding: gzip
        content-type: text/html
        date: Sun, 03 May 2020 19:19:46 GMT
        referrer-policy: no-referrer
        server: nginx/1.14.2
        status: 200
        strict-transport-security: max-age=63072000; includeSubdomains; preload;
        x-content-type-options: nosniff
        x-download-options: noopen
        x-permitted-cross-domain-policies: none
        x-robots-tag: none
        x-xss-protection: 1; mode=block

        It looks good to me and I only found one header entry. Does it mean this policy is working and just not recognized by the test-site?

  • Gerrit sagt:

    Hi,
    may be there ist any idea with my prob.
    Server inst. no prob and no error .
    Browser con ok.
    Connection with smartphone no chance.

    reg
    Gerrit

    • Jan sagt:

      Hi Gerrit,

      when the connection with the browser works, it seems that Jitsi is installed correctly.
      There where some problems after the last update of Jitsi. Another update came this weekend. Maybe you can update and try again?

      Best regards,
      Jan

  • fred sagt:

    Oh, I see now that all is working as intended. The browser test-page just complains about some missing headers:

    Missing Headers
    Content-Security-Policy Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
    X-Frame-Options X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value „X-Frame-Options: SAMEORIGIN“.
    Feature-Policy Feature Policy is a new header that allows a site to control which features and APIs can be used in the browser.

    • Jan sagt:

      Hi Fred,

      probably you have set the headers as shown in the article. Check if you have set the headers twice, because when settings this headers twice, these will be ignored.
      You can also check in the browser console (F12) which headers are set and which are not set.

      Best regards,
      Jan

  • Matthias sagt:

    Hallo Jan,
    ich habe mich an Deine sehr ausführlichen Anleitungen gehalten. Nun beobachte ich folgendes: ich kann zwar Meetings starten (mit „admin“ benutzer), aber wenn ich dann von einem anderen Rechner teilnehmen will, merkt dieser nicht, dass das Meeting schon gestartet ist und legt ein neues an….
    Zudem kann ich kein Passwort für die Meetings vergeben.
    Woran kann das liegen?

    • Jan sagt:

      Hi Matthias,

      nutzt du den Browser, oder den Browser und den Jitsi Desktop Client (hier muss die URL deines eigenen Servers noch eingetragen werden)?
      Ansonsten konnte ich diesen Fehler noch nicht beobachten.
      Vielleicht mal die Logs von Jitsi checken, ob hier etwas interessantes drin steht.

      Gruß,
      Jan

      • Matthias sagt:

        Hi Jan,
        ich nutze zwei verschiedene Rechner mit verschiedenen Browsern und die IOs-App ( da habe ich den Server angepasst…).
        Welche logs sollte ich checken?
        VG
        Matthias

      • Matthias sagt:

        Hallo Jan,

        hier ein Fehler aus jicofo, aus dem ich nicht schlau werde:
        Mai 07 17:44:08 systemd[1]: jicofo.service: Found left-over process 2582 (java) in control group while starting unit. Ignoring.
        Mai 07 17:44:08 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
        Mai 07 17:44:08 jicofo[9734]: /etc/init.d/jicofo: 428: /lib/lsb/init-functions: Cannot fork
        Mai 07 17:44:08 systemd[1]: Starting LSB: Jitsi conference Focus…
        Mai 07 17:44:08 systemd[1]: jicofo.service: Control process exited, code=exited status=2
        Mai 07 17:44:08 systemd[1]: jicofo.service: Failed with result ‚exit-code‘.
        Mai 07 17:44:08 systemd[1]: Failed to start LSB: Jitsi conference Focus.

        • Jan sagt:

          Hi Matthias,

          leider sagt mir das auch erst einmal nichts. Hast du mal versucht, sämtliche Dienste neu zu starten?
          Ansonsten muss ich dich leider auf das Jitsi Forum verweisen, vielleicht kann dort jemand mit dem Fehler was anfangen.

          Gruß,
          Jan

          • Matthias sagt:

            Hi Jan,
            danke für die Antwort. Das Neustarten hat es momentan schlimmer gemacht: ich kann nicht mal mehr mit user und pwd einen Raum eröffenen, ich fliege quasi sofort wieder raus „sorry, etwas hat nicht geklappt…“
            Wenn ich das auf der Reihe habe, wende ich mich ans jitsi forum..
            VG
            Matthias

          • Jan sagt:

            Hi Matthias,

            wenn man direkt wieder rausfliegt, sollte aber in den Jitsi-Logs etwas zu finden sein. Gibt’s da nun andere Meldungen?

            Gruß,
            Jan

  • Raul sagt:

    Hallo Jan,

    vielen Dank für die ausführliche Anleitung. Leider kann ich sie an einigen Punkten aktuell nicht nachvollziehen, auch weil sie von teilweise speziellen Voraussetzungen ausgeht. Dazu weiter unten mehr.

    Ich habe die Installation deshalb nach dieser Anleitung
    https://www.howtoforge.de/anleitung/so-erstellen-sie-ihren-eigenen-videokonferenzserver-mit-jitsi-meet-auf-ubuntu-1804-lts/amp/

    durchgeführt, da sie für mich verständlicher ist.

    Tatsächlich scheint die Installation ohne Fehler durchgelaufen zu sein. Allerdings habe ich das gleiche Problem, von dem zwei Kommentatoren hier in Deinem Beitrag berichten: ich kann den Server aufrufen, einen neuen Raum anmelden, Kamera und Mikro werden sauber erkannt und es scheint alles zu funktionieren. Aber wenn ich von einem zweiten Gerät aus den selben Raum betreten möchte, wird ein neuer Raum (mit der selben URL!) erzeugt, und jeder ist für sich allein in dem Raum. Ich habe es sowohl mit zwei PCs als auch mit iOS / Android App versucht.

    Im Anschluss daran habe ich noch versucht, Authentication (nach Deiner Anleitung) einzurichten – Ergebnis: auch das funktioniert nicht; man kann – wie zuvor auch – den Raum eröffnen, man muss aber trotzdem keine Credentials eingeben.

    Ich habe den Eindruck, dass es eine ganz „einfache“ profane Sache ist, die noch fehlt. Aber ich weiß nicht, wo ich suchen soll.

    Nun zu meiner Umgebung: ich habe eine V-Server bei Strato gehostet und dort ein Ubuntu 18.04 LTS als Grundinstallation zur Verfügung gestellt bekommen. Der Server wird über eine Sub-Domain meet.xxxx.de erreicht. Teilweise musste ich während der Durchführung der oben verlinkten Installationsanleitung Packages installieren, weil nicht alles verfügbar war (z. B. ufw). Anschließend konnte ich aber die weiteren Installationsschritte ohne Probleme durchführen.

    Gerne hätte ich Deine Anleitung verwendet, aber Du gehst von bestimmten Voraussetzungen aus, die für eine Grundinstallation auf einem „blanken“ Server nicht zutreffen. Ich habe im Nachgang zu der oben verlinkten Installation versucht, Deine Anmerkungen nachzuvollziehen, kann diese aber teilweise nicht bestätigen. So müssen z. B. die Verzeichnisse für nginx definitiv nicht angelegt werden, auch gibt es ja keine vorhandene coturn Lösung die überschrieben werden könnte – insofern verwirren die beschriebenen Aktivitäten mehr, als sie einem helfen. Die Installation des Let’s Encrypt Zertifikats wird ebenfalls „sauber“ durch die beschriebene Installationsroutine vorgenommen, d. h. der Server ist über https erreichbar (ich verstehe, dass Du noch ein paar Dinge drum herum gemacht hast, aber diese überfordern mich, ehrlich gesagt). Was sich mir auch nicht erschließt ist, warum die Domain auf localhost aufgelöst werden muss. Auch ist mir nicht ganz klar, warum Du an einer Stelle von einem Router ausgehst, der über 192.168.178.1 (also vermutlich eine FritzBox) erreicht wird wenn doch an anderer Stelle von einer Sub-Domain die Rede ist (es sei denn Du hättest eine statische IP Adresse und der Server steht bei Dir daheim). Die massiven Anpassungen, die Du in der meet.meinedomain.de.config machst sind für mich praktisch nicht nachzuvollziehen. M. E. wurden auch dort die notwendigen Einträge vom Setup korrekt vorgenommen.

    Alles in Allem habe ich den Eindruck, dass Du eine ältere Version von Jitsi installiert hast, die noch diverse Macken hatte. Ich habe die Installation am 18.05.2020 durchgeführt.

    Vielleicht hast Du eine Idee, woran es liegt, dass nicht mehr als ein Client in einem Raum sein kann? Falls ja würde ich mich freuen, wenn Du einen Tipp hättest, der mir weiter hilft.

    Viele Grüße

    Raul

    • Jan sagt:

      Hi Raul,

      erst einmal danke für dein Feedback.
      Ja, die hier gezeigte Installation ist schon etwas speziell, aber das hat auch einen guten Grund: Wenn du Jitsi einfach wie in der von dir verlinkten Anleitung installierst, dann richtet er automatisch nginx, coturn und Jitsi selbst ein. Allerdings ist diese Konfiguration etwas kompliziert, besonders die nginx-Konfiguration. Daher richte ich das alles lieber manuell ein (Zertifikate, nginx, cotourn) und füge dies dann in die Jitsi Meet Konfiguration ein. Dadurch ist das Setup meiner Ansicht nach sauberer – aber das ist sicherlich Geschmackssache.

      Zu deinem Problem mit den getrennten Konferenz-Räumen: Das konnte ich bisher bei meinen Installationen nicht beobachten. Hier hilft wohl nur, die Logs zu durchforsten. Eine gute Anlaufstelle könnte hier auch das Jitsi Forum sein.

      Gruß,
      Jan

    • Oliver sagt:

      Hallo Raul,
      mal kurz zur Info!
      Ich habe es auch erst mit Strato probiert und hatte den identischen Fehler…nach langem suchen und Foren lesen, habe ich mich dazu entschieden, einen V-Server bei Hetzner anzumieten, seit dem läuft es.
      Aber…nur die Absicherung der Instanz klappt nicht. Ich habe alle Dateien angepasst…***cfg.lua; ***config-js; sip-communicator.properties….und restart der Dienst….klappt dennoch nicht, hier suche ich noch den Fehler…
      Gruß
      Oliver

      • Jan sagt:

        Hi Oliver,

        seltsam, du bist nun schon der zweite, der Jitsi nicht auf einem Strato-Server betreiben kann. Obwohl Strato da nach eigener Aussage nichts blockt oder so. Aber eine interessante Beobachtung.
        Bei der Absicherung der Instanz nochmal alle Schritte doppelt und dreifach kontrollieren. Da kann der kleinste Fehler dazu führen, dass das ganze nicht klappt.

        Gruß,
        Jan

        • Rolf Womüller sagt:

          Hier ist noch ein dritter mit Strato, bei dem es nicht läuft. Symptome ähnlich wie oben, zusätzlich ist der VServer dann dermaßen platt, dass er nicht einmal mehr SSH-Zufgriff erlaubt (und wenn, dann kommen ständig Fehlermeldungen). Ich vermute, es liegt an der Virtualisierung, die Strato für die VServer einsetzt (OpenVZ).

          • Jan sagt:

            Hallo Rolf,

            danke für den Hinweis, sehr interessant.
            Hat hier vielleicht schon einmal ein Strato Kunde direkt beim Hoster nachgefragt, um hier vielleicht mal eine offizielle Aussage zu bekommen?

            Gruß,
            Jan

  • Magnus sagt:

    Hallo Jan, vielen Dank für die tolle Anleitung.
    Ich bin enttäuscht wegen der Videoübertragung. Ich habe Ubuntu 18.04 am Start mit 8GB Hauptspeicher und einem Intel® Celeron(R) CPU G3900 @ 2.80GHz × 2.

    Meine Iperf-Messungen am Coturn-Port 3479 brachten schlappe 2.13 Mbit/s. Am Port 443 satte 24.5 Gbit/s. Kannst du mir erklären, warum die Bandbreite derart abweichen und ob ich das irgendwie ändern kann.

    Vielen Dank und schöne Pfingsten

    • Jan sagt:

      Hi Magnus,

      was genau ist dein Problem bei der Videoübertragung? Das läuft eigentlich nicht direkt über den coturn-Port.
      Ebenfalls kannst du mal die CPU-Auslastung während Konferenzen checken. Kann sein, dass das System recht schnell an der Grenze ist.

      Gruß,
      Jan

  • Mat sagt:

    Seit ich den öffentlichen Zugang unterbunden habe verbindet der Server die Video nicht mehr untereinander. Es ist nur ein schwarzes Bild vom Desktop auf dem Handy sichtbar und umgekehrt.

    Hat jemand irgendeine Idee, was es sein könnte, vorher hat es funktioniert.

    • Jan sagt:

      Hi Mat,

      du meinst hier sicher, dass man eine Konferenz nur noch mit User/Passwort eröffnen kann, oder?
      Passen alle anderen Punkte? Hier vielleicht mal die Jitsi-Logs durchgehen, ob irgendwelche Fehler geschmissen werden.

      Gruß,
      Jan

      • Mat sagt:

        Danke für den Hinweis, in einigen Log Files wurde mangelnder Zugriff über Port 5347 gemeldet. Hier habe ich die Firewall geöffnet.

        Ob es das genau war… jedenfalls scheint es jetzt zu gehen.
        Welches sind denn die wirklich wichtigen Log-Files, ich hatte eher planlos gesucht.

        .. und generell für die tolle Anleitung. :-)

        • Jan sagt:

          Hi,

          Jitsi-Logs liegen unter /var/log/jitsi, die Logs von coturn direkt unter /var/log (wenn man es bei den Standard-Einstellungen belässt).
          Aber du hast das Problem ja nun schon gefunden.

          Gruß,
          Jan

  • Robert L. sagt:

    Hallo,

    ich bin etwas irritiert zu den STUN/TURN server config-Einträgen:

    wollte mit coturn beides bereitstellen unter einer subdomain: turn.meinedomain.de

    und habe für diese subdomain dann das folgende tutorial umgesetzt:

    https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn/

    In diesem tut überraschte mich dann aber das:

    „Wir nutzen hier allerdings ebenfalls die eigene coturn-Instanz:

    stunServers: [
    { urls: ’stun:stun.meinedomain.de:5349′ }
    ],

    Ich dachte STUN/TURN hätte ich mit dem coturn-tutorial unter turn.meinedomain.de am laufen, ein getrenntes setup von turn und stun konnte ich nicht ausmachen im tutorial..

    Entsprechend kann der WebRTC trickle ICE test diesen aber nicht korrekt ansprechen:

    The server stun:turn.meinedomain.de:5349 returned an error with code=701:
    STUN host lookup received error.

    bzw.

    The server stun:stun.meinedomain.de:5349 returned an error with code=701:
    STUN host lookup received error.

    Portfreigaben hab ich gemacht, nextcloud z.B. ist auch normal erreichbar auf dem server.

    • Robert L. sagt:

      ok, ich habs lösen können:

      hab die certs für turn.meinedomain.de in einen eigenen Ordner /etc/coturn/certs kopiert und nur leserecht für user turnserver eingerichtet (damit acme.sh die certs unter letsencrypt weiter aktualisieren kann)

      Das Ergebnis zeigt aber nur einen „srflx“ an ..

      Time Component Type Foundation Protocol Address Port Priority
      0.004 rtp host 985767174 udp c3fb3c55-5b06-446c-b651-ee65c344d00b.local 58217 126 | 30 | 255
      0.895 rtp srflx 842163049 udp 192.168.usw.. 58217 100 | 30 | 255
      0.895 Done
      0.898

      Fehlt mir da jetzt noch der STUN-Server ?

    • Jan sagt:

      Hi Robert,

      die jeweiligen Domains sind in den Tutorials eigentlich nur beispielhafte Domains.
      Wenn coturn auf einer Domain turn.meinedomain.de läuft, dann ist natürlich die TURN- als auch die STUN-URL turn.meinedomain.de. Das hast du vollkommen richtig erfasst.
      Allerdings irritiert mich folgendes:

      The server stun:turn.meinedomain.de:5349 returned an error with code=701:
      STUN host lookup received error.

      Die Meldung scheint ja zu bemängeln, dass er wohl die Domain turn.meinedomain.de nicht auflösen kann…

      Gruß,
      Jan

      • Rob sagt:

        Das ist genau das, was ich nicht verstehe..

        er gibt mir

        Time Component Type Foundation Protocol Address Port Priority
        0.004 rtp host 985767174 udp a5fe4707-5980-4bb4-969b-995b43ce7bd9.local 40564 126 | 30 | 255
        0.690 rtp srflx 842163049 udp 192.168.usw… 40564 100 | 30 | 255
        0.691 Done
        0.693

        und auch der ping auf turn.meinedomain.de funktioniert und trotzdem kommt diese Meldung

        The server stun:turn.meinedomain.de:5349 returned an error with code=701:
        STUN host lookup received error.

  • Robert L. sagt:

    im syslog steht:
    WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided

1 2

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.