Getreu dem Motto Stay connected and desinfected (Dubioza Kolektiv Quarantine Show) installieren wir auch im Jahr 2022 noch Jitsi Meet, wohl wissend, das Videokonferenz-Systeme länger bleiben werden als jene Pandemie, die sie 2020 hochgespült hat. Anstatt sich 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 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

A propos Installation: Die läuft – sofern man die Pakete für Debian/Ubuntu von download.jitsi.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.

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 Jitsi-Handbuch 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 Authentifizierung von „anonymous“ auf „internal_hashed“, also mit einem Passwort-Hash, umgestellt:

VirtualHost "jitsi.example.com"
    authentication = "internal_hashed" # 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, aber auskommentiert, so dass zur Aktivierung die beiden Schrägstriche zu Zeilenbeginn entfernt werden und der Hostname 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 /etc/jitsi/jicofo/jicofo.conf ist neben den bestehenden Schlüsseln xmpp und bridge folgender Klammerausdruck zu ergänzen:

jicofo {
    xmpp: {
        [...]
    }
    bridge: {
        [...]
    }
    authentication: {
        enabled: true
        type: XMPP
        login-url: 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 jitsi.example.com geheim

Zum Schluss starten wir die beteiligten Server-Dienste neu:

systemctl restart prosody jicofo jitsi-videobridge2

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

Anbau für Jitsi: Zugang über die Lobby

Ursprünglich purzelte bei Jitsi Meet jeder, der die Adresse kannte, direkt in die Konferenz, ohne vorher anzuklopfen. Seit Sommer 2020 lässt sich für jeden Konferenzraum eine Lobby einrichten. Aktiviert der Administrator in den Sicherheits-Optionen die Lobby-Funktionalität, werden Konferenzteilnehmer erst nach ihrem Namen gefragt und bitten dann um Zugang. Dem Administrator wird angezeigt, wer vor der Tür steht, und er kann den Besucher einlassen – oder auch nicht.

Die nötige Infrastruktur für die Lobby bringen neuere Jitsi-Meet-Versionen bereits mit. Wer eine ältere Installation aktualisiert, muss womöglich noch die Konfigurationsdatei /etc/prosody/conf.d/meet.example.com.cfg.lua erweitern, und zwar an zwei Stellen. Einmal im VirtualHost-Block:

VirtualHost "jitsi.example.com"
    modules_enabled = {
        [...]
        "conference_duration";
        "muc_lobby_rooms";
    }
    [...]
    lobby_muc = "lobby.meet.example.com"
    main_muc = "conference.meet.example.com"

Dahinter muss noch ein neuer Component-Block eingefügt werden:

Component "lobby.jitsi.example.com" "muc"
    storage = "memory"
    restrict_room_creation = true
    muc_room_locking = false
    muc_room_default_public_jids = true

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.

Eine kleine, nicht besonders wissenschaftliche Auswertung auf der Kommandozeile – CPU per top, USS-Speicher per smemstat – zeigt, dass der Haupt-Ressourcenfresser, ein Java-Prozess der Jitsi-Videobridge, vor allem die CPU beansprucht. Bei der Speichernutzung fällt neben der Jideobridge auch noch ein zweiter Java-Prozess – Jicofo – ins Gewicht. Auf einem mit KVM virtualisierten Netcup-vServer mit 8 GB RAM und 2 Kernen entstehen dann folgende Mittelwerte:

Teilnehmer	Speicher (USS)	CPU-Auslastung
4	598 MB	20%
10	771 MB	50%

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 sie bewältigt.