Schnell mal ein Videokonferenz-System mit Jitsi installieren

Auch Edward Snowdon nutzt Jitsi (2017). Foto: Namgig / CC BY-SA

Aus gegebenem Anlass und getreu dem Motto Stay connected and desinfected (Dubioza Kolektiv Quarantine Show) wollen wir heute Jitsi installieren. Das ist ein Videokonferenz-System, das aus quelloffenen Software-Komponenten besteht und auf dem eigenen Server gehostet werden kann. Anstatt sich also auf kommerzielle Anbieter wie Zoom zu verlassen und darauf zu vertrauen, dass solche Dienste die Privatsphäre ihrer Nutzer achten, vertraut der Administrator der eigenen Jitsi-Instanz lieber auf sich selbst.

Die Kernkomponenten dieser Open-Source-Videokonferenz-Lösung sind Jitsi Meet, ein JavaScript-Client, der auch als Android-, IOS- oder Desktop-(Electron)-App verfügbar ist, und die Jitsi Videobridge, die für die effiziente Übertragung zahlreicher Videostreams verantwortlich ist. Darunter arbeitet Prosody, ein in LUA programmierter Server, der wiederum das good old XMPP-Protokoll nutzt.

Probleme und (Un-) Sicherheiten

Jitsi Meet versteht sich auf den Kommunikationsstandard WebRTC, den alle modernen Browser unterstützen (aber unterschiedlich implementieren), weshalb Jitsy Meet auch direkt im Browser läuft, aber die Entwickler Chrome/Chromium und Derivate empfehlen. Aktuell funktioniert Jitsi Meet im Firefox (Version 75.0) bei mir, verursacht aber hauptsächlich mangels Simulcast-Unterstützung Performance-Probleme, je mehr Teilnehmer die Konferenz hat. Echte Probleme macht dagegen die Android-App Die Android-App holen sich auf die Privatsphäre bedachte Menschen aus dem F-Droid-Store, weil die Version bei Google Play laut Exodus drei Tracker an Bord holt. Unter IOS läuft ebenfalls alles perfekt.

Bei zwei Teilnehmern vermittelt Jitsi Meet die Videokonferenz Peer-to-Peer, ähnlich wie Nextcloud Talk. Bei mehr Teilnehmern ist das nicht mehr effizient. Deshalb sendet jeder einzelne Teilnehmer sein Video an die Jitsi Videobridge auf dem Server, der die Verteilung der Streams übernimmt, und zwar mit variablen Datenraten (Simulcast). Das heißt aber auch, dass Mehr-Teilnehmer-Sitzungen (noch) nicht Ende-zu-Ende-verschlüsselt sind. Man muss dem Server-Administrator also trotz allem Vertrauen schenken. Mehr zum Thema Sicherheit, aber auch praktische Nutzungshinweise für Jitsi Meet im Kuketz-Blog.

Wer eine Jitsi-Instanz hostet, sollte auf jeden Fall darauf achten, dass die Übertragung vom Server zum Client per SSL verschlüsselt ist. Man kommt ohnehin kaum darum herum, denn die Jitsi-Entwickler drängen einen bei der Installation recht beharrlich dazu.

Bevor es losgeht

Jitsi Meet auf einem iPhone. Die drei zentralen Schaltflächen: Mikro an/aus, Auflegen, Video an/aus. Über das Sprechblasen-Symbol links führt man einen Text-Chat. Rechts weitere Einstellungen.

A propos Installation: Die läuft – sofern man die Pakete für Debian/Ubuntu von download.jitsy.org verwendet – trotz der diversen Software-Komponenten, die am Ende zusammenspielen müssen, weitestgehend automatisch durch. Ich habe mich an die offizielle Quick-Start-Anleitung gehalten, die bei meinen beiden Installationen sowohl unter Debian 9 (oldstable) als auch Debian 10 (stable) in wenigen Minuten zum Ziel führte. Es schadet auch nichts, wenn auf dem Server bereits andere Websites konfiguriert sind. Allerdings ist laut Nutzer-Berichten Nacharbeit notwendig, wenn eine Administrations-Software wie Plesk den Server im Griff hat.

Vorher sollte man allerdings eine Domain für seinen Videokonferenz-Server am Start haben, und es sollte ein Webserver laufen; Jitsis Installer kennt sowohl Nginx als auch Apache, und findet er einen von beiden, so legt er automatisch einen virtuellen Host für Jitsi Meet  an. Ich verwende hier den Apachen und beispielhaft jitsi.example.com. Dieser Domainname muss auch der Loopback-Adresse in der Datei /etc/hosts hinzugefügt werden. Die Zeile sieht dann in etwa so aus:

127.0.0.1 localhost [...] jitsi.example.com

Der Jitsi-Installer bringt ein Skript mit, das nach der Installation Certbot installiert und ein SSL-Zertifikat von LetsEncrypt ausstellt. Man kann natürlich auch ein bereits vorhandenes Zertifikat nutzen oder sich – falls Certbot bereits installiert ist – selbst ein SSL-Zertifikat generieren:

$ certbot certonly --apache -d jitsi.example.com --rsa-key-size 4096

Privater Schlüssel und Zertifikat sind dann unter /etc/letsencrypt/live/jitsi.example.com/ erreichbar.

Installation aus Fertigteilen

Mit den Paketen aus dem Debian/Ubuntu-Repository geht die Installation und Konfiguration so einfach vonstatten wie ein Bau mit Fertigteilen. Zunächst gilt es allerdings, die Quelle samt GPG-Schlüssel der Paketverwaltung bekannt zu machen:

$ 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 -
$ apt update
$ apt install -y jitsi-meet
apt install jitsi-meet
Reading package lists... Done
Building dependency tree
Reading state information... Done
[...]
The following NEW packages will be installed:
ca-certificates-java java-common jicofo jitsi-meet jitsi-meet-prosody jitsi-meet-web jitsi-meet-web-config jitsi-videobridge2 libavahi-client3
libavahi-common-data libavahi-common3 libcups2 libnspr4 libnss3 libpcsclite1 libxi6 libxrender1 libxtst6 lua-expat lua-filesystem lua-sec
lua-socket lua5.1 openjdk-8-jre-headless prosody ssl-cert uuid-runtime x11-common
0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded.
After this operation, 215 MB of additional disk space will be used.
[...]

Wie man sieht, werden fast 30 Pakete geladen und fast automatisch konfiguriert. Der anschließende Konfigurationdialog benötigt nur noch wenige weitere Angaben:

  • Hostname des Servers: Beispiel jitsi.example.com, ohne http://, eben nur der Hostname
  • SSL-Zertifikat: Wer sich sein Zertifikat schon selbst erstellt hat, wählt die zweite Option: “I want to use my own certificate” und gibt dann die Pfade zur Schlüssel- und zur Zertifikatsdatei an. Bei Letsencrypt also so etwas wie /etc/letsencrypt/live/jitsi.example.com/privkey.pem und /etc/letsencrypt/live/jitsi.example.com/certfullchain.pem.
  • Wer Jitsi mit der Installation von LetsEncrypt betraut hat, muss nach Abschluss des nun noch ein Skript ausführen:
    $ /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

    Nach Eingabe einer (gültigen!) E-mail-Adresse wird der Certbot installiert, holt sich das Zertifikat ab und konfiguriert den VirtualHost in Nginx/Apache entsprechend.

Nun ist unter https://jitsi.example.com die Web-Oberfläche von Jitsi Meet erreichbar. Geschafft! Der Konferenz-Server ist sofort einsatzfähig. Man kann unter Angabe eines Namens einen Konferenzraum öffnen und andere via Link zur Teilnahme einladen.

Die Konferenzraum-Türen schließen

In der Standard-Konfiguration können alle, die diese Adresse kennen, einen Konferenzraum öffnen und andere Menschen zur Konferenz einladen. Das ist nobel, aber vom Server-Admin nicht unbedingt gewünscht, denn viele Konferenzen verbrauchen auch viel Bandbreite. Jitsi läuft zwar auch auf einem vServer, aber je kleiner der Server ist, umso begrenzter sind die Ressourcen. Also empfiehlt sich folgende Strategie:

  • Konferenzräume können nur von Gastgebern, die sich dazu einloggen müssen, eröffnet werden.
  • Den Konferenzraum betreten dürfen alle, die eingeladen sind (also den Link zur Konferenz kennen).
  • Zur Not kann der Gastgeber mit dem Einladungs-Link auch noch ein Passwort verschicken, so dass ungebetene Besucher, die zufällig auf den Link stoßen, ohne Kenntnis dieses Passwortes nicht der Konferenz beitreten können.
Screenshot
Wenn eine Authentifizierung konfiguriert ist, blendet Jitsi Meet einen Hinweistext ein, sobald man eine neue Konferenz eröffnen will. Wer einen Login hat, darf weiter, alle anderen müssen auf den Organisator warten.

Um diese Strategie umzusetzen, muss eine sogenannte Secure domain konfiguriert weren. Hier rückt eine weitere Jitsi-Komponente in den Fokus: Jicofo, zuständig für die Verbindungen zwischen Teilnehmern und der Videobridge. Laut Readme für Jicofo müssen drei verschiedene Konfigurationsdateien mit dem Text-Editor der Wahl angepasst werden:

1. In der Prosody-Konfigurations-Datei /etc/prosody/conf.avail/jitsi.example.com.cfg.lua wird weiter oben die Authetifizierung von “anonymous” auf “internet plain”, also mit Login, umgestellt:

VirtualHost "jitsi.example.com"
authentication = "internal_plain" # statt anonymous

Anschließend wird in derselben Datei – beispielsweise am Ende –  ein neuer Virtual Host für Gäste eingerichtet, der einen anonymen Zutritt gestattet:

VirtualHost "guest.jitsi.example.com"
    authentication = "anonymous"
    c2s_require_encryption = false

Keine Sorge, ein zusätzlicher Eintrag im DNS ist für guest.jitsi.example.com nicht notwendig!

2. In der Konfigurationsdatei von Jitsi Meet unter /etc/jitsi/meet/jitsi.example.com-config.js fügen wir eine Zeile für den neuen virtuellen Guest-Host ein. In meinem Fall war der Eintrag bereits vorhanden und musste nur noch auskommentiert werden (die beiden Schrägstriche zu Zeilenbeginn entfernen), wobei der Hostname aber noch angepasst werden musste:

var config = {
    hosts: {
            domain: 'jitsi.example.com',
            anonymousdomain: 'guest.jitsi.example.com', # hinzufügen oder auskommentieren

3. In der Jicofo-Konfigurationsdatei /etc/jitsi/jicofo/sip-communicator.properties ist ebenfalls eine Zeile zu ergänzen:

org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com

Damit sind alle drei Konfigurationsdateien erfolgreich geändert. Bleibt noch übrig, den oder die Nutzer, die als Gastgeber Konferenzräume einrichten dürfen, samt Passwort anzulegen:

prosodyctl register gastgebername auth.jitsi.example.com geheim

Zum Schluss starten wir die beteiligten Server-Dienste neu:

systemctl restart jicofo jitsi-videobridge2

Danach ist die Eröffnung eines neuen Konferenzraumes nur noch nach Login möglich.

Alles ist möglich. Alles eine Frage der Hardware.

Prinzipiell kann man Konferenzen mit kleinen Teams oder Familienmitgliedern auf einem VPS abhalten. Generell gilt: Je mehr Prozessor-Kerne, desto besser. Der Admin kann in der Konfigurationsdatei die Standard-Videogröße (720p) limitieren und somit dem Server Luft verschaffen. Das geht natürlich auf Kosten der Video-Qualität. Im eigenen Browser oder der App kann man ebenfalls die Videogröße heruntersetzen. Auch lässt sich das eigene Video ganz ausschalten. Das wäre dann eine Telefon-Konferenz. Oder man bestreitet einen Text-Chat.

Wer Erfahrungen mit Jitsi gesammelt hat, kann gerne einen Kommentar hinterlassen, welche Hardware – virtueller Server oder dediziert, Mehrkern-Prozessor oder Stromsparer – eingesetzt wird und wieviele Konferenzteilnehmer*innen sie bewältigt.

Schreibe einen Kommentar