Kategorien
#OCHQ8 Aktuelles

lessions learned 4

technische learnings Teil 5

5 Jetzt schnappen wir uns den Jitsi-Server

Was ich da Schritt für Schritt alles gemacht habe:

  • Eine (sub)Domain passend auf den zukünftigen Jitsi-Meet Server zeigen lassen
  • Eine Ubuntu 20.04 Instanz erschaffen
  • den Hostnamen in /etc/hosts und via hostnamectl korrekt auf den DNS-Namen setzen
  • Den Jitsi-Meet Server habe ich nach einer einfachen Anleitung im Internet aufgesetzt, am wichtigsten erscheint mir der Hostname, sonst kann weder letsencrypt noch der Serverzugriff richtig von statten gehen. Die übliche Benutzerauthentifizierung um einen Meetingraum zu erstellen habe ich mir gespart, schließlich soll ja via JWT-Token authentifiziert werden. Ganz am Anfang spare ich mir auch das, um die Zusammenarbeit zwischen Workadventure und Jitsi-Meet Server grundlegend zu testen.
  • Die JWT-Authentifizierung ist so einfach wie schwierig umzusetzen. Eigentlich muss nur das Modul jitsi-meet-tokens installiert werden, die Abhängigkeitsprobleme können einen aber in den Wahnsinn treiben. Sollte dieser aber einmal laufen, kann man die Authentifizierung auf Token umstellen. Der virtuelle Host (aus hostnamectl) wird von „plain“ auf authentication = „token“ umgestellt. App_id und app_secret werden vergeben. Dem „muc“ wird noch die „token_verification“; ermöglicht.
  • Die verwendeten app_id und app_secret werden jetzt in der .env des Workadventure-Servers als JITSI_ISS= und SECRET_JITSI_KEY= eingetragen.
  • Nach Docker compose down / up sollte der Workadventure Server sich jetzt beim Jitsi anmelden und einen Meetingraum generieren. Die Authentifizierung bremst ein wenig beim erstellen oder betreten des Raumes, bietet aber ein gutes Maß an Privatsphäre.
  • Um die Last auf dem Jitsi-Server zu verteilen kann Jitsi-Meet von Hause aus eine sogenannte Videobridge benutzen und verteilt die Meetingräume so auf verschiedenen verbundenen Servern. Diese Option hatten wir zwar vorbereitet, kam aber Aufgrund der auf „Wahnsinnige Geschwindigkeit“ dimensionierten Server nicht zum Einsatz. Wir hatten geplant bei Performance-Engpässen eine (fertig konfigurierte) Videobridge zu klonen, auf 32 Prozessoren und 64 GB Ram hochzuskalieren und zu starten, im Prinzip könnten wir das beliebig oft wiederholen und damit das Jitsi-Meet Backend erweitern.

Schreibe einen Kommentar

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.