© Andriy Popov, 123RF

Ein Artikel der letzten Ausgabe stellte die Videokonferenz-Lösung Jitsi Meet vor. Der aktuelle Artikel zeigt, wie Anwender Jitsi Meet auf einem eigenen Debian-Server einrichten.

Der Artikel schließt das Einrichten von SSH-Zugängen, DNS-Records und HTTPS-Zertifikaten über Let’s Encrypt mit ein, um ein vollständiges Bild zu geben. Am Ende lässt sich der Jitsi-Server [1] unter »https://jitsi.example.com« erreichen.

Zum Einsatz kam ein einfacher virtueller Server mit Debian 10 bei einem deutschen Hoster. Solche Maschinen erreicht man üblicherweise über einen vom Hoster vorkonfigurierten SSH-Zugang als User root. Wer sich weiterhin mit Root-Rechten anmelden möchte, sollte zunächst den SSH-Zugang absichern. Alternativ besteht die Möglichkeit, einen einfachen Nutzer anzulegen und Root-Rechte auf dem Server anzufordern. Auf Gründen der Einfachheit arbeitet der Artikel aber mit Root als Standardnutzer.

SSH-Zugang absichern

Ein abgesicherter SSH-Zugang sollte am besten einen anderen als den Standard-Port 22 verwenden, eine Authentifizierung nur per Key erlauben und eine Anmelden mit Passwort verbieten.

Dazu erzeugt der Nutzer zunächst ein 4096 Bit langes Schlüsselpaar. Den öffentlichen Schlüssel schiebt er auf den virtuellen Server, den privaten (geheimen) behält er auf dem lokalen Rechner. Die Befehlsfolge aus den ersten beiden Zeilen von Listing 1 erzeugt im Home-Verzeichnis das Schlüsselpaar.

$ cd
$ ssh-keygen -t rsa -b 4096
[...]
$ ssh-copy-id -i id_example_com.pub User@example.com

Der Admin sollte den Keys einen eindeutigen Namen geben, etwa »id_example_com«. Eine optionale »passphrase« schützt den Zugriff auf den privaten Key, falls jemand den eigenen Rechner kapert.

Den privaten Schlüssel (ohne Endung) verschiebt der Nutzer in das Verzeichnis »~/.ssh/« des lokalen Rechners. Den öffentlichen (mit der Endung ».pub«) lädt er er auf den Server hoch. Dazu prüft er zunächst, ob er sich über die Passphrase des Hosters auf seinem Server anmelden kann. Klappt das, wechselt er in das Verzeichnis mit dem öffentlichen Schlüssel und lädt diesen auf den Server hoch (Listing 1, Zeile 4).

Der Befehl schiebt den öffentlichen Schlüssel nicht nur nach »~/.ssh/«, sondern schreibt ihn auch gleich in die Datei »~/.ssh/authorized_keys«. Im Erfolgsfall erscheint die Nachricht »Number of key(s) added: 1«. Wenn der Nutzer sich auf dem entfernten Rechner anmeldet, landet er im Home-Verzeichnis und sollte in der Datei »~/.ssh/authorized_keys« den hochgeladenen Public Key vorfinden.

Danach sorgt er dafür, dass er sich künftig nur noch per Key anmelden muss. Das lässt sich auf dem Server in der Konfigurationsdatei für den SSH-Server (»/etc/ssh/sshd_config«) festlegen. Dort gilt es wie in Listing 2 gezeigt einige Optionen zu ändern und die Kommentare vor anderen zu entfernen. Nach dem Ändern startet der Admin den Dienst auf dem Server neu (»systemctl restart ssh«). Nun sollte das SSH-Login ohne Passwort funktionieren.

Port 54321 // vorher Port 22
[...]
PubkeyAuthentication yes
[...]
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
[...]
PasswordAuthentication no
[...]
# Optional: SSH als einfacher Nutzer
PermitRootLogin no

Bei Nutzern, die auf ihrem Client mehrere Schlüssel verwenden, erscheint beim SSH-Login mitunter die Meldung »Too many Authentication Failures«. Das lässt sich auf dem lokalen Rechner über die Konfigurationsdatei »~/.ssh/config« ändern. Wer die Datei wie in Listing 3 ergänzt, kann sich direkt über »ssh example« beim Server anmelden. Auch die beschriebene Fehlermeldung, die vom Austesten zu vieler Schlüssel rührt, verschwindet dann.

Host example
  HostName 77.88.99.1
  Port 54321
  IdentityFile ~/.ssh/id_example_com
  IdentitiesOnly yes
  User root

Feuerwand aufstellen

Damit der Server nicht mehr offene Ports anbietet als nötig – und Jitsi Meet öffnet einige Ports – richtet der Admin im nächsten Schritt eine Firewall ein. Der Autor macht es sich einfach, installiert die Uncomplicated Firewall und gibt die für Jitsi Meet benötigten Ports frei (Listing 4).

# apt install ufw nginx
# ufw allow 54321/tcp
# ufw allow 443/tcp
# ufw allow 4443/tcp
# ufw allow 80/tcp
# ufw allow 10000/udp
# ufw enable

Wichtig ist hier vor allem, auch den (neu gewählten) Port für SSH freizugeben, andernfalls sperrt sich der Admin aus der Maschine aus. Zugleich installiert Listing 4 Nginx mit, um später den HTTPS-Zugang zu testen.

Jitsi-Subdomain einrichten

Noch trägt der Server nur eine IP-Adresse, etwa 77.88.99.0. Höchste Zeit also, diese mit einem Domain-Namen zu verknüpfen. Beides erledigt der Admin üblicherweise beim Hoster selbst.

Zunächst benötigt er einen Domain-Namen, den er in der Regel mietet. Dann verknüpft er diesen oder beliebige Subdomains über einen DNS-Eintrag mit der IP-Adresse 77.88.99.0. Das Mieten eines Domain-Namens kann etwas Zeit in Anspruch nehmen, das Einrichten des DNS-Records ebenfalls – das sollten Admins mit knappem Zeitbudget berücksichtigen.

Besitzt er einen Domain-Namen (der Artikel bleibt bei example.com), richtet er den Nameserver ein. Das Interface zum Einrichten von DNS-Einträgen sieht bei jedem Anbieter etwas anders aus (Abbildung 1). Der Admin verknüpft hier über den ersten »A«-Record den gemieteten Domain-Namen (etwa example.com) mit der IP-Adresse. Beim gewählten Hoster repräsentiert ein »@« diesen Domain-Namen.

Abbildung 1: Die A-Records verknüpfen den Domain-Namen und die Subdomain mit der IP-Adresse des Servers.

Beim zweiten »A«-Record ergänzt dann die Subdomain »jitsi« den vorhandenen Domain-Namen, und das Konstrukt »jitsi.example.com« verweist ebenfalls auf die IP-Adresse. Nutzer landen später allerdings bei einer Subdomain von Nginx, auf der Jitsi läuft.

Auch hier muss der Admin etwas Geduld aufbringen, denn Änderungen an Nameserver-Einträgen brauchen mitunter Zeit, um sich im DNS-System zu verbreiten. Die TTL (Time to Live, in Sekunden) gibt Auskunft über die entsprechenden Zeiträume. In Abbildung 1 ist eine typische TTL von 86400 Sekunden zu sehen – es dauert also bis zu einem Tag, bis Änderungen greifen. Wer will, kann die TTL verkürzen, was aber die Server stärker belastet und nicht immer funktioniert. Ob andere DNS-Server die neuen (Sub-)Domain-Namen bereits erkennen, verrät zum Beispiel DNSChecker [2]. Ist der DNS-Eintrag erfolgreich, sollte sich unter »http://jitsi.example.com« der Nginx-Server melden.

Jitsi Meet auf die Platte

Im nächsten Schritt gilt es, Jitsi Meet zu installieren. Listing 5 zeigt die dazu nötigen Schritte für Debian 10. Während der Installation fragt die Paketverwaltung zunächst die Domain ab, auf der Jitsi laufen soll (Abbildung 2). Dann stellt sie die Frage, ob der Anwender ein selbst signiertes Zertifikat erzeugen möchte oder ein vorhandenes verwenden will. Die erste Option erlaubt es, später auch Zertifikate von Let’s Encrypt zu integrieren, also fällt die Wahl auf sie.

# echo 'deb https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
# wget -qO -  https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -
# apt update
# apt install jitsi-meet

Abbildung 2: Beim Installieren von Jitsi Meet lässt sich die neu eingerichtete Subdomain bereits angeben.

Let’s Encrypt für die Jitsi-Domain

Nach Installation der Software erreicht der Anwender Jitsi erstmals in Firefox oder Chromium über »https://jitsi.example.com«. Allerdings muss er noch eine Abfrage abnicken, ohne die der Webbrowser das selbst unterzeichnete Zertifikat nicht akzeptieren würde.

Smartphone-Benutzer erhalten über die Jitsi-App hingegen noch keinen Zugriff auf die Jitsi-Räume. Das ändert sich spätestens mit der Installation von Let’s-Encrypt-Zertifikaten, die auch Smartphone-Apps akzeptieren. Zeit also, den eingebauten Mechanismus zum Installieren der Zertifikate zu bemühen (Abbildung 3). Dazu empfiehlt es sich, Jitsi und die dazugehörigen Dienste zu stoppen und dann das entsprechende Skript auszuführen (Listing 6).

Abbildung 3: Praktischerweise bringt Jitsi Meet gleich ein eingebautes Let’s-Encrypt-Skript mit, um die Videokonferenzlösung per HTTPS abzusichern.

# systemctl stop jicofo.service jitsi-videobridge2.service prosody.service nginx.service
# cd /usr/share/jitsi-meet/scripts/
# ./install-letsencrypt-cert.sh

Die Schlüssel (»fullchain.pem« und »privkey.pem«) landen unter »/etc/letsencrypt/live/jitsi.example.com/«. Anschließend lassen sich die angehaltenen Dienste wieder hochfahren, und der Anwender erreicht Jitsi Meet per HTTPS über den Browser und die Smartphone-Apps – zumindest, wenn diese nicht antik sind.

Jitsi-Performance

Aufgrund von Problemen mit der Startreihenfolge der Dienste (der Nginx-Start schlug fehl) legte der Autor zwei einfache Skripte in »/usr/bin/« an: »jitsi_start« und »jitsi_stop«. Abbildung 4 zeigt das Startskript; vermutlich ließe sich auch der Systemd-Service anpassen.

Abbildung 4: Ein Skript vereinfacht nicht nur das Starten und Stoppen der Dienste rund um Jitsi Meet. Es verhinderte im Test auch Probleme aufgrund einer falschen Startreihenfolge.

Admins wollen zudem häufig wissen, mit wie vielen Teilnehmern Jitsi Meet zurechtkommt. Laut Hauptentwickler Damian Minkov [3] gibt es, zumindest auf den Servern des Projekts selbst, ein hartes Limit von 75 Teilnehmern. Aber schon bei 35 Teilnehmern leide die Performance deutlich, hieß es noch im März 2020.

Für Konferenzen, Klassen und Universitätskurse bietet es sich daher an, das Video auf Youtube zu streamen. Diese Plattform geht auch bei vielen Teilnehmern nicht in die Knie, es gibt über den Chat einen Feedback-Channel. allerdings handelt es sich dann nicht mehr wirklich um eine Videokonferenz, sondern eher um ein Videostreaming.

Doch es gibt auch einige Tuning-Optionen für Konferenzen, mit denen sich ein lesenswerter Thread auf der Community-Plattform von Jitsi beschäftigt [3]. Die betreffen wahlweise die Infrastruktur (Nginx, Debian), die Videobridge oder das Interface von Jitsi Meet.

So lassen sich zum Beispiel in der Datei »/etc/nginx/nginx.conf« die »worker_connections« hochsetzen. Eine ganze Reihe von Einstelloptionen bietet auch die Datei »/etc/jitsi/meet/jitsi.example.com-config.js«. Hier reduziert der Admin zum Beispiel die Auflösung für die übertragenen Videos (Abbildung 5), was bei den Teilnehmern Bandbreite spart.

Abbildung 5: Die Video-Auflösung für die Teilnehmer auf einen Wert von 480 zu senken, entlastet den Jitsi-Server.

Es gibt eine Option, um reine Audiokonferenzen zu starten (»startAudioOnly: true,«). Die Last sinkt auch dann, wenn die Konferenzteilnehmer einer Versammlung zunächst ohne Audio- und Video-Support beitreten. Bei sehr vielen Teilnehmern hilft es zudem, wenn die Zuschauer ihre Kameras nur dann einschalten, wenn sie etwas sagen möchten.

Wer schließlich Konferenzen im hohen zweistelligen oder dreistelligen Teilnehmer-Bereich plant, sollte einen Blick auf die DevOps-Guides werfen [4]. Die zeigen, wie sich Jitsi Meet für den Cloud-Einsatz skalieren lässt.