Jitsi betreibt selbst einige Server, um unkompliziert, anonym und werbefrei eine Videokonferenz zu starten (Jitsi-Meet; diese Server stehen vermutlich in den USA). Auch andere Organisationen weltweit betreiben öffentliche Jitsi-Server, hier eine Liste. Die Kommunikation mittels Jitsi ist bei einer Konferenz mit zwei Teilneher:innen Ende-zu-Ende verschlüsselt, d.h. auf dem Weg von einem Kommunikationspartner zum anderen sind alle (Video-, Audio- und Text-) Daten verschlüsselt unterwegs und somit vor Lauschern sicher. Wo die Server stehen und wer die Server betreibt, über die der verschlüsselte Datenverkehr läuft, scheint daher mit Blick auf Datensicherheit und Datenschutz in diesem Fall weniger wichtig.

Bei mehr als zwei Teilnehmer:innen (z.B. Gruppentherapie) findet jedoch nach derzeitigem Kenntnisstand (noch) keine Ende-zu-Ende-Verschlüsselung statt. In diesem Fall ist nur der Transportweg verschlüsselt, auf dem Server selbst liegen die Daten jeoch – zumindet für die Dauer einer Videokonferenz – unverschlüsselt vor.

Außerdem fallen in jedem Fall neben den verschlüsselten Inhalten auch unverschlüsselte Metadaten an. Das Problem ist z.B. von WhatsApp bekannt: Die Nachrichteninhalte sind zwar Ende-zu-Ende verschlüsselt, der Betreiber (Facebook) erhält aber trotzdem viele wertvolle Daten, eben die unverschlüsselten Metadaten (wer hat wann wie lange mit wem kommuniziert usw.).

Da Jitsi vollständig anonym genutzt werden kann, beschränken sich die anfallenden Metadaten auf die IP-Adressen der Kon­fe­renz­teil­nehmer. Das ist im Sinne der Datensparsamkeit löblich, dennoch ist zu beachten, dass IP-Adressen nach geltender deutscher Rechtsprechung zu den personenbezogenen Daten gehören.

Schließlich gilt für jeden Service, der über fremde Server läuft – ob kommerziell oder nicht –, dass man dem Betreiber vertrauen muss, dass der Service wirklich so datensicher implementiert und konfiguriert ist wie versprochen. Einem seriösen, der DSGVO verpflichteten Anbieter, mit dem eine Vereinbarung zur Auftragsverarbeitung geschlossen wurde, kann dieses Vertrauen entgegengebracht werden, einem öffentlichen Server nicht ohne weiteres.

Fazit: Um die Kontrolle über alle anfallenden Daten zu behalten, auch die unverschlüsselten Metadaten, muss Jitsi auf dem eigenen Server betrieben werden. Nur so wird die Privatsphäre aller Teilnehmer*innen optimal geschützt und der Videokonferenz-Service kann auf diese Weise sicher und DSGVO-konform betrieben werden.

Außerdem ist es nur bei einer selbst betriebenen Jitsi-Instanz möglich, sinnvolle Zugangsbeschränkungen zu konfigurieren, so dass z.B. nur die Therapeutin eine neue Sitzung anlegen und starten kann.

Ein eigener Server kann ein Computer sein, der in den eigenen Praxisräumen hinter verschlossenen Türen steht, aber z.B. auch ein angemieteter Root-Server bei einem vertrauenswürdigen Anbieter. Beide Varianten haben Vor- und Nachteile, die jede:r für sich abwägen muss.

Ein wichtiger Punkt, der einen Computer in den eigenen Räumen u.U. disqualifiziert, ist die Upload-Bandbreite. Internetanschlüsse für Privatkunden aber auch für viele kleinere Geschäftskunden sind in Deutschland häufig asymmetrisch ausgelegt, d.h. einer guten Download-Bandbreite steht eine bisweilen dürftige Upload-Bandbreite gegenüber. Der eigene Videokonferenz-Server, der sämtliche Kommunikation zentral verwaltet, empfängt aber nicht nur Daten von den Teilnehmer:innen (Download), sondern verteilt diese Daten auch an die Teilnehmer:innen weiter (Upload). Eine ungenügende Upload-Bandbreite kann daher zu einem Flaschenhals werden und zu unbefriedigender Audio- und Videoqualität führen oder gar zu Verbindungsabbrüchen.

Mit einem gehosteten Root-Server umgeht man dieses Problem. Diese Server stehen in Rechenzentren, die symmetrisch und mit hoher Bandbreite an das Internet angeschlossen sind. Weitere Vorteile: Die Rechenzentren sind klimatisiert, verfügen über eine Notstromversorgung und die Hardware wird rund um die Uhr überwacht. Auch lässt sich die Leistung eines gemieteten Servers (CPUs, Arbeits­speicher, Datens­peicher) in aller Regel kurzfristig und einfach an veränderte Bedürfnisse anpassen. Bei eigener Hardware ist das aufwändiger oder nur durch einen Neukauf zu realisieren. Wenn in der Praxis kein (geeigneter) Computer zur Verfügung steht, ist man mit einem Miet-Server auch viel schneller am Start: Von der Online-Bestellung bis zur Bereitstellung vergehen meist nur Minuten; einen Server zu kaufen dauert Tage bis Wochen…

Die folgende Anleitung geht von einem vergleichbaren System aus, also einem angemieteten Server, der ausschließlich für das Jitsi-Videokonferenzsystem zuständig ist. Vieles lässt sich jedoch auch auf andere Konstellationen übertragen.

Jitsi kann entweder auf herkömmliche Weise direkt in ein (Linux-) System installiert werden oder als Docker-Container betrieben werden.

Herkömmliche Installation

Die Jitsi-Installationsanleitung (und auch unsere Anleitung in Abschnitt 5) beschreibt die notwendigen Schritte für ein Debian- oder Ubuntu-System. Versierte Linux-Nutzer können versuchen, Jitsi auch unter anderen Betriebssystemen zu installieren, ansonsten lautet die klare Empfehlung, den eigenen Jitsi-Server mit Debian (oder Ubuntu) auszustatten.

Betrieb in Docker-Containern

Läuft eine Anwendung in einem Container, fungiert das eigentliche Server-Betriebssystem nur als Wirtsystem und ist von untergeordneter Bedeutung. Die verfügbare Anleitung für ein containerisiertes Jitsi-System nutzt als Container-Lösung docker und docker-compose, so dass im Prinzip jedes Docker-kompatible System als Wirt geeignet ist (Achtung: Aktuelle Systeme aus dem Redhat-Umfeld (RHEL, CentOS, Fedora) sind auf eine andere Container-Lösung um­ge­stiegen (podman) und haben (noch) keinen vollwertigen Ersatz für docker-compose). Da sich Debian als Server-Betriebssystem über viele Jahre bewährt hat und nach wie vor auf Docker setzt, ist auch hier Debian eine gute Wahl.

Fazit: Wenn andere Anforderungen nicht dagegen sprechen, ist Debian die beste Wahl für den gemieteten Server; aktuell ist Debian 10 (Codename Buster). Eine Debian-Minimalinstallation reicht aus. Insbesondere kann bei einem gemieteten Server auf graphische Desktop-Software verzichtet werden, weil der Server ohnehin über eine Text-Konsole administriert wird. Die meisten Server-Hoster bieten verschiedene Betriebssysteme an, die sozusagen auf Knopfdruck installiert werden können. Alternativ gibt es in der Regel die Möglichkeit, eigene CDROM-Abbilder (z.B. ein heruntergeladenes Debian-Abbild) zum Hoster hochzuladen und auf dem Miet-Server zu installieren.

Unsere Erfahrung reicht nicht aus, um hier eine klare Empfehlung zu geben, und auch die Experten sind sich – soweit wir das übersehen – nicht einig, ob bzw. wann eine herkömmliche Installation einer Container-Lösung vorzuziehen ist oder umgekehrt.

Auf einem Server, der außer für Jitsi auch noch für andere Dinge zuständig ist, ist die Containerlösung u.U. vorzuziehen. Das gilt um so mehr, wenn docker bereits auf dem Server installiert und aktiviert ist; in diesem Fall ist Jitsi tatsächlich sehr schnell einsatzbereit. Auf einem frisch aufgesetzten, dezidierten Server erscheint uns dagegen eine herkömmliche Installation sinnvoller und übersichtlicher zu konfigurieren.

Bei einem gemieteten Server erhält man in der Regel eine feste IPv4-Adresse, um mit dem Server zu kommunizieren. Für administrative Aufgaben und Testzwecke reicht das aus, für den produktiven Einsatz ist aber eine aussagekräftige URL sicher besser geeignet, z.B.:

https://tele.praxis.de

anstatt eine IP-Adresse wie:

https://192.168.94.127

Wenn man bereits eine Domain besitzt (z.B. praxis.de) und die Möglichkeit besteht, Sub-Domains zu konfigurieren (z.B. tele.praxis.de), kann man einfach die neue Sub-Domain anlegen und auf die IPv4-Adresse des Servers verweisen. Das funktioniert auch über Anbieter hinweg: Wenn Sie z.B. bei Anbieter A Ihre Website hosten und Ihre Domains verwalten, der Server aber von Anbieter B bereit gestellt wird, können Sie bei Anbieter A eine Weiterleitung der Sub-Domain zu einer IP-Adresse im Netzwerk von Anbieter B einrichten.

Verfügen Sie nicht über eine eigene Domain, können Sie entweder bei Ihrem Server-Hoster eine beantragen (eine de-Domain kostet etwa 5 €/Jahr) oder Sie nutzen einen Service für dynamisches DNS, haben dann aber nicht die volle Kontrolle über den Domainnamen. Für einen Server in den eigenen Räumen hinter einem Internetanschluss ohne feste IP-Adresse ist dynamisches DNS ebenfalls die Methode der Wahl, um den Server von außen erreichbar zu machen. Besitzer:innen einer Fritzbox können hierfür den MyFritz-Dienst nutzen.

Ein gemieteter Server wird in aller Regel per Text-Konsole verwaltet, d.h. alle Arbeiten (im wesentlichen Software-Installation und das Bearbeiten von Konfigurationsdateien) werden ohne den gewohnten Komfort einer graphischen Benutzeroberfläche erledigt. Die Verbindung zwischen dem eigenen Rechner und dem Server wird über das verschlüsselte ssh-Protokoll hergestellt. Dafür wird eine IP-Adresse, ein Benutzername und ein Passwort benötigt (nach dem Erstkontakt kann auch ein Zugang mit Public Key statt Passwort eingerichtet werden; s. Abschnitt 4.2).

Wenn der Server mit fertig installiertem Betriebssystem bereit gestellt wird, erhalten Sie die Angaben vom Hoster (nach dem ersten Login nicht vergessen, mit dem Befehl passwd das Passwort zu ändern). Bei einem selbst installierten Betriebssystem benötigen Sie vom Hoster nur die IP-Adresse, da Sie im Laufe der Installation selbst ein Benutzerkonto einrichten.

Liegen alle Angaben vor, öffnen Sie auf ihrem eigenen Rechner eine Text-Konsole:

• Windows: In aktuellen Versionen von Windows 10 genügt vermutlich die Eingabeaufforderung oder PowerShell; ansonsten scheint Putty eine bewährte ssh-Anwendung zu sein; ich habe weder mit dem einen noch mit dem anderen Erfahrung.

• macOS: Öffnen Sie die Terminal-Applikation.
• Linux: Öffnen Sie eines der zahlreichen Terminals.

In der Text-Konsole tippen Sie dann einen Befehl nach dem folgenden Muster ein (alle Befehle werden durch Drücken der ENTER-Taste ausgeführt):

ssh <Name>@<Ihre-IP-Adresse>

z.B.:

ssh root@192.168.94.127

Bestätigen Sie die folgende Abfrage zum Schlüsselaustausch mit yes und geben Sie auf Nachfrage Ihr Passwort ein – ab jetzt arbeiten Sie auf dem Server. Um die ssh-Sitzung zu beenden, tippen Sie exit. Die hier vorgestellte Anmeldemethode als Root mit Passwort ist anfangs notwendig, sollte aber besser früher als später deaktiviert und durch ein sichereres Verfahren ersetzt werden (s. Abschnitt 4.2).

Diese Anleitung geht davon aus,

• dass Jitsi auf einem frisch aufgesetzten Server mit Debian-10-Minimalsystem installiert wird,
• dass dieser Server ausschließlich für Jitsi zuständig sein soll,
• dass Sie über einen Server-Zugang mit administrativen Rechten verfügen (root-Zugang oder sudo-Rechte),
• dass Sie eine (Sub-) Domain konfiguriert haben, die auf diesen Server verweist.

Die Anleitung nutzt als Beispiel die Domain praxis.de und die Subdomain tele. Die Basis-URL des installierten Systems würde demnach am Ende https://tele.praxis.de lauten. Entsprechende Angaben in der Installationsanleitung müssen Sie natürlich an ihre (Sub-) Domain anpassen. In den folgenden Listings ist die Beispiel-Domain farbig markiert: tele.praxis.de; in den Befehlen müssen Sie diesen Teil jeweils durch Ihre Domain ersetzen, in den Konfigurationsdateien steht nach der Installation meist schon Ihre richtige Domain anstatt meiner Besipiel-Domain.

Befehle, die Sie nach der Verbindung via ssh im Server-Terminal eingeben müssen, sind in solchen Kästen gelistet:

# befehl

Das #-Zeichen steht für den sogenannten Prompt, der bei Ihnen sicher anders aussieht (eher so: root@servername:~#) und der natürlich nicht zu kopieren ist. Wenn Sie nicht als root sondern als normaler Benutzer mit sudo-Rechten eingeloggt sind (ihrname@servername:~$), müssen Sie den meisten Befehlen ein sudo voranstellen.

Ausschnitte aus Konfigurationsdateien, in denen Sie etwas editieren müssen, sehen so aus:

...
Lorem ipsum dolor sit amet
Consetetur sadipscing elitr
...

Wichtige Zeilen, in denen etwas geändert werden soll, sind gelb markiert, die Auslassungspunkte deuten an, dass es sich um einen Ausschnitt handelt und davor und dahinter weiterer Text stehen kann.

Nachdem Sie sich zum ersten Mal mit Ihrem neuen Server verbunden haben, stellen Sie sicher, dass das System auf dem neuesten Stand ist:

# apt update && apt -y upgrade

Aus Sicherheitsgründen sind folgende Vorarbeiten unbedingt empfehlenswert:

• Umstellung der ssh-Anmeldung auf Public-Key-Authentication (Anleitungen gibt es zahlreich im Internet, Stichwort ‘‘ssh anmeldung ohne passwort’')

• Root-Zugang per ssh verbieten, so dass man sich nur noch als ‘normaler’ Nutzer verbinden kann. Für administrative Aufgaben nutzt man sudo oder wechselt in das Root-Konto.

• Installation einer einfachen Firewall und Konfiguration für ssh sowie Jitsi (die Frage, die nach dem Befehl ufw enable gestellt wird, kann mit y beantwortet werden):

# apt -y install ufw
# ufw enable
# ufw allow in ssh
# ufw allow in 80/tcp
# ufw allow in 443/tcp
# ufw allow in 10000/udp
# ufw allow in 3478/udp
# ufw allow in 5349/tcp
# ufw status verbose

• Schutz der ssh-Anmeldung vor Brute-Force-Angriffen per Firewall:

# ufw limit ssh

# apt -y install fail2ban

Aus Komfortgründen ziehe ich den Texteditor micro den vorinstallierten Alternativen vi oder nano vor; das ist natürlich optional:

# apt -y install curl
# cd /usr/local/bin
# curl https://getmic.ro | bash

Wenn Sie einen anderen Editor nutzen möchten, ersetzten Sie in den folgenden Listings micro durch den Befehl für Ihren Editor.

Jetzt wird es ernst. Wenn Sie Jitsi herkömmlich installieren möchten, geht es mit Abschnitt 5 weiter, wenn Sie die Container-Lösung be­vor­zugen, springen Sie zu Abschnitt 6.

Zuerst wird der Hostname des Servers geändert, so dass er identisch mit Ihrer Subdomain ist (tele durch Ihre Subdomain ersetzen!):

# hostnamectl set-hostname tele

Dann erstellen Sie ein Backup der Datei /etc/hosts und öffnen Sie zum Editieren:

# cp /etc/hosts /etc/hosts.BKP
# micro /etc/hosts

Prüfen bzw. ergänzen Sie die folgenden Angaben. Die Zeile 127.0.0.1 localhost ist vermutlich schon vorhanden. Die zweite Zeile müssen Sie ergänzen; sie beginnt mit der öffentlichen IP-Adresse Ihres Servers (s. Abschnitt 3.1, gefolgt von Ihrer URL:

127.0.0.1   localhost
a.b.c.d     tele.praxis.de
...

Falls Sie weitere Angaben (IPv6) vorfinden, lassen Sie diese unverändert.

Als nächstes wird der Webserver nginx installiert:

# apt -y install nginx-full
# systemctl enable --now nginx.service

Da Jitsi (noch) nicht in den offiziellen Paketquellen vertreten ist, muss nun eine neue Quelle angelegt werden. So kann Jitsi in Zukunft im Rahmen eines gewöhnlichen System-Updates aktuell gehalten werden:

5.2.1 Authentifizierung

Wenn der Start einer neuen Sitzung durch eine Benutzer-Authentifizierung geschützt werden soll, sind die folgenden 5 Schritte not­wendig. Danach muss man zum Start einer Sitzung Benutzername und Passwort eingeben, nicht jedoch um einer bereits gestarteten Sitzung beizutreten. Wenn auf die Konfiguration einer Authentifizierung verzichtet wird, kann jede beliebige Person, die Ihren Server findet, darüber Videokonferenzen abhalten.

Zur Einrichtung müssen zunächst drei Konfigurationsdateien bearbeitet werden. (Es ist ratsam, vor der Bearbeitung wichtiger Dateien eine Sicherungskopie der Originaldatei anzulegen.) Dann muss mindestens ein Benutzerkonto erstellt werden und zum Abschluss werden alle Server-Komponenten neu gestartet.

Schritt 1: Der XMPP-Server prosody

Die folgenden Befehle wechseln in das \emph{prosody}-Verzeichnis, legen eine Sicherungskopie der Konfigurationsdatei an und öffnen die Datei dann zur Bearbeitung (anstatt micro funktioniert auch nano oder vi):

# cd /etc/prosody/conf.avail/
# cp tele.praxis.de.cfg.lua tele.praxis.de.cfg.lua.BKP
# micro tele.praxis.de.cfg.lua

Im Abschnitt VirtualHost "tele.praxis.de" (hier steht nach der obigen Installation schon Ihre korrekte Domain!) ändern Sie die Option authentication (Zeilen, die mit ‘--’ beginnen, sind in lua-Dateien Kommentare).

Schritt 2: Die Jitsi-Komponente jicofo

Die folgenden Befehle wechseln in das jicofo-Verzeichnis, legen eine Sicherungskopie der Konfigurationsdatei an und öffnen die Datei dann zur Bearbeitung:

# cd /etc/jitsi/jicofo/
# cp sip-communicator.properties sip-communicator.properties.BKP
# micro sip-communicator.properties

Fügen Sie am Ende der Datei die folgende Zeile hinzu:

...
org.jitsi.jicofo.auth.URL=XMPP:tele.praxis.de

Schritt 3: Die Jitsi-Komponente meet

Die folgenden Befehle wechseln in das meet-Verzeichnis, legen eine Sicherungskopie der Konfigurationsdatei an und öffnen die Datei dann zur Bearbeitung:

# cd /etc/jitsi/meet/
# cp tele.praxis.de-config.js tele.praxis.de-config.js.BKP
# micro tele.praxis.de-config.js

Schritt 4: Benutzerkonto erstellen

Mit dem folgenden Befehl legen Sie ein Benutzerkonto an. Statt benutzername wählen Sie einen passenden Namen, statt passwort ein sicheres Passwort (bitte notieren; das Passwort wird verschlüsselt gespeichert und kann nicht rekonstruiert werden). Nach dem gleichen Muster können bei Bedarf (auch später noch) weitere Benutzerkonten angelegt werden:

3 prosodyctl register benutzername tele.praxis.de passwort

Schritt 5: Aktivierung

Zum Abschluss werden alle Server-Komponenten neu gestartet, um die Änderungen zu aktivieren:

# systemctl restart nginx.service prosody.service jicofo.service jitsi-videobridge2.service

Standardsprache

Die Standardsprache der Oberfläche ist auf Englisch voreingestellt. Um auf Deutsch zu wechseln, muss die meet-Konfiguration bearbeitet werden (die Originaldatei haben wir bereits im letzten Abschnitt gesichert):

# cd /etc/jitsi/meet/
# micro tele.praxis.de-config.js

Suchen Sie die beiden folgenden Zeilen:

...
    // Default language for the user interface.
    // defaultLanguage: 'en',
...

und aktivieren/ändern Sie die Option defaultLanguage:

...
    // Default language for the user interface.
    defaultLanguage: 'de',
...

STUN-Server

In der gleichen Datei werden die STUN-Server konfiguriert, eine Art Vermittlungsstelle zwischen Teilnehmer:innen. Falls hier noch Google-Server vorkonfiguriert sind (ältere Jitsi-Versionen), sollten diese aus Gründen der Datensparsamkeit durch DSGVO-konforme Server ersetzt werden. Falls nicht, spricht trotzdem nichts dagegen, hier weitere Server einzutragen (STUN-Server-Liste). (Der Hinweis auf die Google-STUN-Server in ältere Jitsi-Versionen stammt vom sehr lesenswerten Blog von Mike Kuketz.)

Third Party Requests ausschalten

Ebenfalls in der meet-Konfiguration kann für mehr Privatsphäre und Datensparsamkeit nach der folgenden Option gesucht:

    // disableThirdPartyRequests: false,

und diese aktiviert werden:

    disableThirdPartyRequests: true,

Ressourcen regulieren

Bevor Sie die meet-Konfiguration schließen, können Sie bei Bedarf einige Voreinstellungen ändern, um Ressourcen wie Bandbreite und CPU-Last (Server und Clients) zu regulieren.

Bei Bandbreitenproblemen kann die maximale Videoauflösung global reduziert werden. Suchen Sie nach dem folgenden Abschnitt:

...
    constraints: {
        video: {
            aspectRatio: 16 / 9,
            height: {
                ideal: 720,
                max: 720,
                min: 240
            }
        }
    },
...

Logging

Der Logging-Level der Videobridge-Komponente ist auf INFO vor­ein­ge­stellt. Mit dieser Einstellung werden unnötigerweise personenbezogene Daten, nämlich die IP-Adressen der Teilnehmer:innen erfasst. Um dies zu ändern, wechseln Sie in das Konfigurationsverzeichnis der Videobridge-Komponente, legen eine Sicherungskopie der Logging-Konfiguration logging.properties an und öffnen die Datei dann zur Bearbeitung:

# cd /etc/jitsi/videobridge
# cp logging.properties logging.properties.BKP
# micro logging.properties

Suchen Sie nach:

.level=INFO

und ändern Sie die Zeile in:

.level=WARNING

Mobile Jitsi-Apps

Bezüglich Datensparsamkeit sind die mobilen Jitsi-Apps aus den offiziellen Stores für Android und iOS problematisch, da sie Tracker enthalten (vgl. Analyse von Exodus Privacy. Einzig die Jitsi-App, die aus dem alternativen Android-Store F-Droid bezogen werden kann, ist frei von Trackern (für iOS ist mir keine Tracker-freie Variante be­kannt). Daran können Sie als Betreiber einer Jitsi-Server-Instanz natürlich nichts ändern. Allerdings können Sie verhindern, dass Teil­nehmer:innen, die Ihr Angebot mit einem Android-Gerät nutzen wollen und die Jitsi-App noch nicht installiert haben, ein Installations-Link präsentiert wird, der zum Google-Play-Store führt. Stattdessen kann ein Link zum F-Droid-Store voreingestellt werden.

In der Standard-Konfiguration erlaubt der Webserver Nginx die veralteten und unsicheren TLS-Protokolle TLSv1 und TLSv1.1 (Stand Frühjahr 2020; in aktuellen Nginx-Versionen ist dies möglicherweise nicht mehr der Fall). Um die verschlüsselte https-Verbindung robuster zu machen, sollten diese beiden Protokolle deaktiviert werden; stattdessen kann man die neuste TLS-Version TLSv1.3 zusätzlich zu TLSv1.2 erlauben. Die folgenden Befehle wechseln in das zuständige Nginx-Verzeichnis, legen eine Sicherungskopie der Konfigurationsdatei an und öffnen die Datei dann zur Bearbeitung (Ihre Konfigurationsdatei ist selbstverständlich nach Ihrer Domain benannt):

# cd /etc/nginx/sites-available
# cp tele.praxis.de.conf tele.praxis.de.conf.BKP
# micro tele.praxis.de.conf

Im zweiten server-Block finden Sie die Option für die erlaubten Protokolle:

...
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
...

Entfernen Sie TLSv1 und TLSv1.1 und fügen Sie TLSv1.3 hinzu:

...
    ssl_protocols TLSv1.2 TLSv1.3;
...

Nach Änderungen an der Nginx-Konfiguration muss der Web-Server neu gestartet werden, um die Änderungen zu aktivieren:

# systemctl restart nginx.service

Weitere Konfigurationsvorschläge finden Sie im Jitsi-Wiki. Die regelmäßig aktualisierten Empfehlungen zu einer sicheren SSL/TLS-Kon­figuration, veröffentlicht von den SSL Labs, liefern Hinter­grund­infor­mationen.

Sämtliche Dateien, die das Aussehen der Jitsi-Oberfläche steuern, finden sich im Verzeichnis /usr/share/jitsi-meet bzw. in dessen Unterverzeichnissen. Wir beginnen mit einer Konfigurationsdatei, die zahlreiche Einstellungen bereitstellt, um die Oberfläche weiter anzupassen (falls Sie interface_config.js bereits im Abschnitt 5.2.2 gesichert haben, um den F-Droid-Link einzufügen (vgl. Mobile Jitsi-App), lassen Sie hier den zweiten Befehl weg):

# cd /usr/share/jitsi-meet/
# cp interface_config.js interface_config.js.BKP
# micro interface_config.js

Sie können relativ gefahrlos verschiedene Einstellung ändern und den Effekt sofort – manchmal auch mit kurzer Verzögerung – im Browser überprüfen (Seite neu laden). Hier ein paar Beispiele:

TOOLBAR_ALWAYS_VISIBLE: true
Verhindert das Ausblenden der Bedienelemente (Stummschalten, Auflegen usw.).

JITSI_WATERMARK_LINK: 'https://tele.praxis.de'
Verlinkt das Logo oben links (das Sie durch Ihr eigenes ersetzen können) zu Ihrer Homepage.

APP_NAME: 'Praxisname'
Der Praxisname erscheint in Bookmarks und an einigen anderen Stellen.

GENERATE_ROOMNAMES_ON_WELCOME_PAGE: false
Stellt die wenig brauchbaren Vorschläge für Sitzungsnamen ab.

DISPLAY_WELCOME_PAGE_ADDITIONAL_CARD: true
Zeigt selbst erstellte Inhalte auf der Startseite an (s.u.).

Falls Sie die Oberfläche kaputt konfigurieren, stellen Sie einfach die Originaldatei wieder her:

# cd /usr/share/jitsi-meet/
# mv interface_config.js.BKP interface_config.js

Sollten Sie für Ihren Web-Auftritt ein Favicon in Form einer Datei favicon.ico vorliegen haben. können Sie damit das Jitsi-Favicon ersetzen. Übertragen Sie die Datei favicon.ico von ihrem Rechner auf den Server (im Terminal mit scp oder mit einem graphischen scp-Tool) und kopieren Sie die Datei dann in das korrekte Ver­zeich­nis:

# cp favicon.ico /usr/share/jitsi-meet/images/

In das gleiche Verzeichnis (/usr/share/jitsi-meet/images) können Sie Ihr Logo kopieren, das dann oben links anstatt des Jitsi-Logos erscheint. Benennen Sie Ihr Logo – sofern es im SVG-Format vorliegt – in watermark.svg um oder verweisen Sie in interface_config.js hinter der Option DEFAULT_LOGO_URL auf eine andere Datei (neben SVG funktionieren auch PNG-Graphiken).

Wer noch weitergehende Anpassungen wünscht, die nicht über die Einstellungen in den Konfigurationsdateien zu bekommen sind, muss an’s Eingemachte. Um z.B. die sehr kleine Schrift im Text-Chat größer zu machen, muss man einen Wert in der Style-Datei ändern (zumindest habe ich bisher keine andere Möglichkeit gefunden):

# cd /usr/share/jitsi-meet/css/
# cp all.css all.css.BKP
# micro all.css

Suchen Sie mit STRG-F nach chatconversation und ändern Sie den Wert der css-Eigenschaft font-size, z.B. auf 14pt. Auf diese Weise lassen sich alle möglichen Aspekte der Oberfläche an die eigenen Wünsche anpassen. Voraussetzung ist ein bisschen Detektivsinn und zumindet Grundlagenwissen in HTML und CSS (sowie ein Skript oder ein Dienst, um das komprimierte CSS besser lesbar zu machen, z.B. unminify.com).

Wenn Sie auf der Startseite selbst erstellte Inhalte (z.B. einen Link zu Ihrer Website, zu einem Impressum und/oder zu einer Daten­schutz­er­klärung) anzeigen wollen, bearbeiten Sie die folgende Datei:

# cd /usr/share/jitsi-meet/static/
# cp welcomePageAdditionalCard.html welcomePageAdditionalCard.html.BKP
# micro welcomePageAdditionalCard.html

Fügen Sie ihre Inhalte zwischen die template-Tags ein, z.B.:

<template id = "welcome-page-additional-card-template">
  <style type="text/css">
    .additional-card-content {
      margin: 2em 2em;
      font-size: 12pt;
    }
  </style>

  <div class="additional-card-content">
    <p>
      <a href="https://www.praxis.de" target="_blank">Praxisname</a>
    </p>
  </div>
</template>

Damit die Inhalte angezeigt werden, muss in der Datei interface_config.js die Option DISPLAY_WELCOME_PAGE_CARD den Wert true erhalten (s.o.). Falls Ihre Inhalte Links enthalten, funktionieren diese nur nach einer weiteren Änderung in der css-Datei:

# cd /usr/share/jitsi-meet/css/
# micro all.css

Suchen Sie mit STRG-F nach welcome-watermark und entfernen Sie die css-Eigenschaft height: 100%.

Um andere Texte auf der Startseite (oder an anderer Stelle) an­zu­passen, kann die Datei bearbeitet werden, die die deutschen Übersetzungen für die eingebauten (englischsprachigen) Text-Komponenten enthält:

# cd /usr/share/jitsi-meet/lang/
# cp main-de.json main-de.json.BKP
# micro main-de.json

Ersetzen Sie die vorgegebenen Texte durch eigene Kreationen, z.B. den Titel, den Untertitel und die Knopf-Beschriftung auf der Start­seite:

...
   "headerTitle": "Logopädische Praxis Mustermann"
...
   "headerSubtitle": "Willkommen bei unserem Teletherapie-Angebot.",
...
   "startMeeting": "Therapiesitzung starten",
...

Das funktioniert aber nur, wenn Sie die Standardsprache auf Deutsch umgestellt haben (s. Abschnitt 5.2.2) und Ihre Nutzer keine andere Sprache einstellen…

Zum Abschluss noch einmal der Hinweis: Alle in diesem Abschnitt vorgeschlagenen Anpassungen müssen gesichert und nach einem Jitsi-Update ggf. rekonstruiert werden. Je mehr Anpassungen Sie vornehmen, desto aufwändiger wird somit ein Jitsi-Update. Damit dies nicht dazu führt, dass wichtige System-Updates generell hinaus geschoben werden, kann es u.U. sinnvoll sein, die Jitsi-Komponenten von regelmäßigen System-Updates auszunehmen und nur dann zu aktualisieren, wenn danach genug Zeit ist, die Anpassungen zu rekonstruieren. Dadurch kann das Debian-System in kurzen Update-Intervallen aktuell gehalten werden, während Jitsi-Updates in längeren Abständen eingespielt werden. Das ist insofern nicht ideal, als auch Jitsi natürlich sicherheitsrelevante Updates erhalten kann, die möglichst schnell installiert werden sollten, aber es ist auf jeden Fall besser, als längere Zeit generell auf Updates zu verzichten. Eine simple Befehlsfolge, welche das gesamte System mit Ausnahme der Jitsi-Komponenten aktualisiert, könnte z.B. so aussehen:

# apt-mark hold coturn jicofo prosody jitsi-meet jitsi-meet-web jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-videobridge2
# apt update && apt -y upgrade
# apt-mark unhold coturn jicofo prosody jitsi-meet jitsi-meet-web jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-videobridge2

6.1 Docker installieren

Bei einem frisch aufgesetzten Server mit Debian-Minimalinstallation ist die Container-Verwaltung docker und das Hilfsprogramm docker-compose noch nicht installiert. Das kann mit

# docker -v 
# docker-compose -v

überprüft werden. Wird eine Fehlermeldung ausgegeben (command not found o.ä.), steht eine Installation an, wird eine Versionsnummer ausgegeben (Docker version ...), haben Sie Glück gehabt und können mit Abschnitt 6.2 fortfahren.

Die Docker-Installation muss mit administrativen Rechten erfolgen. Wenn Sie nicht mit dem Root-Konto auf dem Server eingeloggt sind, stellen Sie sicher, dass Ihr Nutzerkonto sudo-Rechte hat und stellen Sie den folgenden Befehlen ein sudo voran.

# apt update
# apt -y install curl gnupg2 git ca-certificates install apt-transport-https software-properties-common
# curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
# add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
# apt update
# apt install docker-ce docker-ce-cli containerd.io

Zur Installation von docker-compose genügen diese zwei Befehle:

# curl -L "https://github.com/docker/compose/releases/download/1.28.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose

Beim Download mit curl muss die Versionsnummer angegeben werden (1.28.4 ist die aktuelle Version im Februar 2021). Schauen Sie vor dem Download hier, ob es eine neuere Version gibt und ersetzen Sie im curl-Befehl bei Bedarf die Versionsnummer.

Hat alles geklappt, sollten diese beiden Befehle eine Versionsnummer ausgeben:

# docker -v 
# docker-compose -v

Auch hier gilt: Wenn Sie nicht mit dem Root-Konto auf dem Server eingeloggt sind, stellen Sie sicher, dass Ihr Nutzerkonto sudo-Rechte hat und stellen Sie den folgenden Befehlen ein sudo voran. Der folgende Befehl erstellt auf dem Server das Verzeichnis docker-jitsi-meet und kopiert die benötigten Dateien in dieses Verzeichnis:

# git clone https://github.com/jitsi/docker-jitsi-meet

Als nächstes wechseln Sie in das neue Verzeichnis, erstellen aus der vorgegebenen Beispiel-Konfiguration (env.example) die später tatsächlich verwendete Konfiguration (.env) und öffnen diese zum Bearbeiten (statt micro geht auch nano oder vi etc.):

# cd docker-jitsi-meet
# cp env.example .env
# micro .env

Die Konfigurationsmöglichkeiten sind sehr umfangreich und zu jeder Option gibt es eine kurze Erklärung in der Datei. Zeilen, die mit “#” beginnen, sind Kommentare und werden bei der Konfiguration nicht berücksichtigt. Das betrifft natürlich die Erklärungen, aber auch manche Optionen sind durch ein vorangestelltes “#” deaktiviert. Durch Entfernen des Kommentarzeichens können diese Optionen aktiviert werden. Die Optionen selbst folgen dem einfachen Muster NAME_DER_OPTION=Wert. Die folgenden Änderungen halten wir für sinnvoll (Erläuterungen zu den Änderungen folgen unten).

Zeilen 1 – 2

Damit der Docker-Container und damit das Jitsi-System auf dem Server über die Standarports erreichbar ist und beim Aufruf der Jitsi-URL keine Port-Angabe notwendig ist, können die Standard-Ports für http (80) und https (443) eingestellt werden. Das ist dann sinn­voll, wenn der Server nur für Jitsi zuständig ist und keine anderen Webinhalte ausliefert. Ohne diese Änderung würde die Adresse des Servers so lauten:

https://tele.praxis.de:8443

anstatt so:

https://tele.praxis.de

Zeilen 3 – 5

Gültige TLS-Zertifikate sind notwendig, damit das Jitsi-System per https, also mit Transportverschlüsselung aufgerufen werden kann. Das ist unerlässlich, weil moderne Browser einer Website, die ohne Transportverschlüsselung, also nur per http aufgerufen wird, die Freigabe von Kamera und Mikrophon verweigern – d.h. ohne vertrauenswürdige Zertifikate und ohne https keine Videokonferenz!

Der Jitsis Docker-Container hat einen Mechanismus eingebaut, der automatisch kostenlose TLS-Zertifikate von der Zertifizierungsstelle Let’s Encrypt bezieht. Mit ENABLE_LETSENCRYPT=1 wird dieser Mechanismus aktiviert. Bei der Domain- und Email-Option für Let’s Encrypt müssen natürlich gültige Werte angegeben werden, tele.praxis.de und info@praxis.de dienen im Beispiel oben nur als Platzhalter.

Zeilen 6 – 8

Die Authentifizierungseinstellungen können nach Bedarf angepasst werden. Die vorgeschlagene Konfiguration erlaubt das Starten einer neuen Video-Sitzung nur nach Authentifizierung, also nach Eingabe eines Benutzernamens und eines Passwortes (ENABLE_AUTH=1). Ist eine Sitzung gestartet, können weitere Personen jedoch ohne Au­then­ti­fi­zierung teilnehmen (ENABLE_GUESTS=1), wobei die Mög­lich­keit, eine neu gestartete Sitzung mit einem Passwort zu schützen, bestehen bleibt. Die dritte Option legt die Art der Authentifizierung fest, dazu später mehr.

Zeile 9

Aufruf per http ohne Transportverschlüsselung verhindern, http-Aufrufe werden automatisch nach https umgeleitet.

Zeile 10

Mit dieser Option kann die Aufnahmefunktion aktiviert (1) oder deaktiviert (0) werden.

Wenn alle Änderungen vorgenommen wurden, kann die Konfiguration mit STRG-S (nano: STRG-O) gespeichert werden. Der micro-Editor wird mit STRG-Q (nano: STRG-X) beendet.

Die folgenden Einstellungen können im laufenden System vorgenommen werden. Änderungen sind sofort bzw. mit kurzer Verzögerung wirksam.

6.3.1 Sprache

Nach einer Neuinstallation ist Englisch als Standardsprache für die Benutzeroberfläche eingestellt. Das kann jede:r Teilnehmer:in individuell in den Einstellungen ändern, es ist aber auch möglich, die Oberfläche standardmäßig auf Deutsch umzustellen. Öffnen Sie hierzu mit dem folgende Befehl die entsprechende Konfigurationsdatei :

# micro ~/.jitsi-meet-cfg/web/config.js

Suchen Sie die Zeile

    // defaultLanguage: 'en',

und ändern Sie die Zeile wie folgt:

    defaultLanguage: 'de',

In der Datei lassen sich etliche weitere Optionen anpassen. Schauen Sie sich ruhig um, aber seinen Sie vorsichtig …

6.3.2 Oberfläche

Im gleichen Verzeichnis gibt es eine zweite Konfigurationsdatei, in der weitere Aspekte der Benutzeroberfläche angepasst werden können:

# micro ~/.jitsi-meet-cfg/web/interface_config.js

Einige Beispiele:

TOOLBAR_ALWAYS_VISIBLE: true
Verhindert das Ausblenden der Bedienelemente (Stummschalten, Auflegen usw.).

SHOW_JITSI_WATERMARK: false
Entfernt das Jitsi-Logo von der Startseite.

APP_NAME: 'Praxisname'
Der Praxisname erscheint in Bookmarks und an einigen anderen Stellen.

GENERATE_ROOMNAMES_ON_WELCOME_PAGE: false
Stellt die wenig brauchbaren Vorschläge für Sitzungsnamen ab.

6.3.3. Innereien

Weitere Anpassungen können vorgenommen werden, indem Dateien innerhalb der laufenden Container verändert werden. Hier ist zu beachten, dass diese Änderungen verloren gehen, sobald die Container heruntergefahren werden. Wichtige Änderungen müssen also gut dokumentiert werden, damit sie einfach repliziert werden können, wenn die Conatiner neu gestartet werden. Versierte Nutzer können auch die Container-Konfiguration entsprechend anpassen (z.B. das Dockerfile im Verzeichnis ~/docker-jitsi-meet/web).

Die folgenden Anpassungen werden im web-Container vor­ge­nommen, ermitteln Sie also zunächst dessen ID:

# docker container ls

Der Befehl listet die vier laufenden Jitsi-Container auf. Suchen Sie nach der Zeile, die in der zweiten Spalte jitsi/web enthält. Die ID finden Sie in der ersten Spalte:

CONTAINER ID     IMAGE            COMMAND     ...
7b0b23e2e447     jitsi/jicofo     "/init"     ...
17ede23c6557     jitsi/jvb        "/init"     ...
6a3cbff5e60a     jitsi/web        "/init"     ...
4578fb6c3c2f     jitsi/prosody    "/init"     ...

Für die folgenden Beispiele nutze ich die ID 6a3cbff5e60a; diese müssen Sie durch die von Ihnen ermittelte ID ersetzen.

Um ein eignenes Favicon anzuzeigen, laden Sie ihr Favicon (favicon.ico) zunächst auf den Server hoch, dann kopieren Sie die Datei mit dem folgenden Befehl in den web-Container:

# docker cp favicon.ico 6a3cbff5e60a:/usr/share/jitsi-meet/images/

Im Idealfall haben Sie jetzt ein funktionstüchtiges Jitsi-Videokonferenzsystem auf dem eigenen Server am Laufen – Glückwunsch!

Der eigene Server will aber auch gepflegt und evtl. weiter konfiguriert und gehärtet werden. Wenn ich Zeit und Informationen finde, werde ich versuchen, diese Anleitung in dieser Hinsicht auszubauen. Oder Sie informieren sich selbst über empfehlenswerte Maßnahmen (und sagen mir gerne Bescheid!). Bis dahin sollte der Server zumindest regelmäßig (Sicherheits-) Updates erhalten. Dazu stellen Sie eine ssh-Verbindung her und führen auf dem Server die folgenden Befehle aus (Docker-Nutzer bauen einfach neue Container aus aktualisierten Image-Dateien):

# apt update && apt -y upgrade

Falls Sie Ihre Jitsi-Instanz wie in Abschnitt 5.2.4 beschrieben an Ihre Bedürfnisse angepasst haben, finden Sie am Ende jenes Abschnitts Hinweise für eine differenziertere Update-Strategie.

Sehr gerne können Sie mir Verbesserungsvorschläge oder anderes Feedback schicken!