Eigene Jitsi Meet Instanz installieren (Docker / Ubuntu / Nginx)

Jitsi Meet ist eine Open Source Videokonferenz Software die durch die Corona Pandemie in aller Munde ist. Ich persönliche finde Jitsi Meet eine der besten Alternativen zu Diensten wie Zoom, Teams und Co. Warum dies so ist und wie man Jitsi Meet benutzt beschreibe ich hier im
Tutorial: Videokonferenzen mit Jitsi Meet.

Ich möchte euch in dieser Anleitung zeigen wie die adminForge Jitsi Meet Instanz aufgesetzt wurde.

Aufbau des Setups:

  • Ubuntu 18.04 LTS als Betriebssystem
  • Bereits laufender NGINX Webserver. Wir verwenden diesen als Proxy.
  • Let’s Encrypt SSL Zertifikat (oder anderes)
  • Aktuelle Docker CE Version
  • Aktuelle Docker Compose Version
  • Eine (Sub)domain wird benötigt die auf die IP-Adresse des Servers verweist – wie meet.adminforge.de

Offene Ports in der Firewall:

  • 80/tcp
  • 443/tcp
  • 4443/tcp
  • 10000/udp

Punkt 1: Docker CE installieren

Wir installieren Docker CE nach Anleitung.

Benötigte Pakete installieren:

GPG Key herunterladen:

Repository hinzufügen Ubuntu:

Repository hinzufügen Debian:

Docker CE installieren:

Docker Compose installieren wir mit diesen beiden Befehlen:

Eine aktuelle Docker Compose Version, oder andere Installationsmöglichkeiten, gibt es hier: Docker Compose Anleitung

Punkt 2: Jitsi Meet Docker herunterladen

Zuerst erstellen wir uns einen Docker Ordner:

Wir wechseln in den Ordner und klonen das Git Repository:

Nun wechseln wir in diesen Ordner und kopieren die .env Konfigurationsdatei:

Jetzt erstellen wir sichere Passwörter mit dem vorhandenen Script:

Die Konfigurationsordner in unserem Verzeichnis .jitsi-meet-cfg müssen wir manuell erstellen:

Punkt 3: Jitsi Meet .env anpassen

Bevor es losgeht müssen wir ein paar Mindeständerungen vornehmen.

Ich habe den Konfigurationsordner von Jitsi Meet gerne im selben Docker Pfad. Darum passen wir diesen an:

Da wir später unseren Nginx Proxy vorschalten stellen wir die HTTP Ports von Jitsi Meet auf localhost um:

Nun estellt die Timezone in Deutschland auf Europe/Berlin:

Nun tragen wir die (Sub)domain die wir für diese Jitsi Meet Instanz verwenden möchten ein:

Optional: Wenn euer Server im LAN betrieben wird (NAT), dann muss hier die Docker Host IP-Adresse eingetragen werden:

Einen STUN Server für P2P Videokonferenzen (max. 2 Personen) hinterlegen wir ebenfalls. Damit werden nicht die von jitsi.net oder damals Google verwendet. Ihr dürft gerne die adminForge STUN Server verwenden:

Punkt 4: Nginx Port 80 vHost erstellen

Nginx installieren.

Wir wechseln in den Nginx vHost Ordner.

Nun erstellen wir einen Port 80 vHost für Let’s Encrypt und zur Weiterleitung an HTTPS.

Wir aktivieren die Konfiguration.

Nun laden wir die Konfiguration.

Wir erstellen uns ein kostenloses Let’s Encrypt SSL-Zertifikat. Ich beschreibe ausführlich wie dies funktioniert hier.

Eure Domain meet.example.com muss vor diesem Schritt bereits auf die Server IP-Adresse auflösen!

Let’s Encrypt Kurzanleitung:

Punkt 5: Nginx Port 443 vHost erstellen

Nun erstellen wir einen vHost für SSL, bsp. meet.example.com_ssl.conf. Bitte passt nach eurem Bedarf alles an.

WICHTIG: Damit der Jitsi Meet Desktop Client funktioniert, darf der Security Header X-Frame-Options nicht gesetzt werden und Content-Security-Policy nur abgeschwächt!

Wenn alles angepasst ist erstellen wir den Symlink, ersetzt hier auch wieder meet.example.com:

Jetzt prüfen wir ob alles korrekt ist un laden Nginx Konfigurationen neu:

Punkt 6: Docker Container starten

Die Docker Container können nun gestartet werden. Wir verwenden dazu den sehr praktischen docker-compose Befehl, der uns gleich alle 4 Container korrekt startet:

Ob alles läuft prüfen wir mit diesem Befehl:

Stoppen könnt ihr alles mit docker-compose down.

WICHTIG: Wenn Anpassungen an der .env gemacht wurden, muss der Config-Ordner .jitsi-meet-cfg gelöscht werden um die Änderungen wirksam zu machen!

Fertig! Unter https://meet.example.com ist eure eigene Jitsi Meet Instanz nun erreichbar.

Als nächstes: Jitsi Meet Docker Instanz anpassen

Euer adminForge Team

UnterstützenDas Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.
Unterstütze unsere Arbeit mit einer Spende.
Dominion

Dominion

Linux Systemadministrator

Das könnte dich auch interessieren …

30 Antworten

  1. Avatar Matthias sagt:

    Danke für die Anleitung. Hab das gestern auch mal gemacht. Ich muss aber sagen, dass das ganze mit dem offiziellen Ubuntu-Paket DEUTLICH einfacher ging, als per Docker. Nach 5min war man durch. Keine weitere Konfiguriation nötig.

  2. Avatar Christian sagt:

    Hallo,
    vielen Dank für diese ausführliche Anleitung.
    Ich komme bis zum Ende von Punkt 3 gut klar, danach ist unklar wie es weitergeht.
    Punkt 4 sagt: Nginx Proxy vHost erstellen – in Ordner wechseln cd /etc/nginx/sites-available/ und Datei „meet.example.com.conf“ erstellen, alles nach Bedarf anpassen. Dann der Hinweis auf SSL Let’s Encrypt.
    Was von beidem mache ich zuerst? Und wenn ich erst der Let’s Encrypt-Anleitung folge, bekomme ich immer eine Fehlermeldung:
    _CURL=’curl -L –silent –dump-header /root/.acme.sh/http.header -g ‚
    _ret=’0′
    code=’200‘
    MEINEDOMAIN.de:Verify error:Invalid response from http://MEINEDOMAIN.de/.well-known/acme-challenge/LETSENCRYPTCODE [MEINE IP]:
    Debug: get token url.

    Ich komme da leider nicht weiter und würde mich sehr über Hilfe freuen!

    • Dominion Dominion sagt:

      Die Anleitung habe ich angepasst. Schau mal ob es so verständlicher ist.

      • Avatar Christian sagt:

        Super, vielen Dank.
        Nun klappt auch das Zertifikat (auch wenn es zwischendurch den Fehler gab, dass der acme.sh-Befehl nicht existiert, obwohl ich acme.sh per curl geladen habe).
        Nun tut sich aber ein neues Problem auf: Punkt 5 – Nginx-Konfiguration testen.
        nginx -t gibt aus:
        nginx: [emerg] unknown directive „ssl_early_data“ in /etc/nginx/sites-enabled/meet.MEINEDOMAIN_ssl.conf:16
        nginx: configuration file /etc/nginx/nginx.conf test failed

        Da ich den hier beschriebenen Teil im Code aber nur kopiert habe und Dr. Google mir nicht weiterhelfen kann, frage ich hier noch mal. Würde mich riesig über eine Lösung freuen!

  3. Avatar Gero sagt:

    Vielen Dank, super Anleitung!
    Damit Jitsi Meet automatisch startet, kann man noch einen kleine Systemd Unit erstellen nach diesem Vorbild:
    https://github.com/docker/compose/issues/4266#issuecomment-302813256
    Dann kann man die Instanz mit systemctl enable docker-compose@docker-jitsi-meet zum Systemstart vormerken.

  4. Avatar c0by sagt:

    Tolle Anleitung, danke. Eine Frage noch.

    Das wären alle Ports die man mit ufw freigeben müsste?

    0.0.0.0:10000->10000/udp, 0.0.0.0:4443->4443/tcp
    5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp

  5. Geniale Anleitung, alles hat so funktioniert wie es hier beschrieben war. Wer möchte kann meinen Jitsi Server gern verwenden.

    https://meet.blankenberg.eu

  6. Avatar Stefan sagt:

    Auch von mir, vielen Dank für die gute Anleitung. Hat alles funktioniert.
    Allerdings habe ich nun links und rechts einen schwarzen Balken beim Videobild. Nur übern Browser, App kein Problem. Gleicher Browser öffentlicher Server tritt dieses Problem nicht auf.
    Hast du evtl. noch einen Tipp für mich?

  7. Avatar kultex sagt:

    danke für die Anleitung – ich habe vorab eine Frage. Funktioniert die Anleitung auch für einen Pi4 oder Rock64 mit 4GB? Ich brauche die Instanz nur im LAN für 2 Laptops, die auf der Bühne stehen. Die Konferenz wird projiziert.

    Ich möchte auf Tournee nicht davon abhängig sein, dass ich einen guten Internetanschluss vom Haus zur verfügung gestellt bekomme.

    Guß

  8. Avatar Plastikschnitzer sagt:

    Kann es sein, dass Jitsi an den Docker Containern einiges geändert hat? Habe die Anleitung vor ein paar Wochen befolgt, lief ohne Probleme.

    Jetzt an einem anderen Projekt versucht, kommt nur noch Error 502 am nginx.
    Ports in der .env sind jetzt anders (8000 und 8443) aber die kann man ja frei wählen und sollten kein Problem sein, daran liegt es auch nicht.
    Das restart.sh skript enthält auch andere Container-Namen.

    Kann jemand bestätigen, dass die Anleitung hier noch aktuell ist?

    • Dominion Dominion sagt:

      Da wurde nichts angepasst, das Datum hat sich nur geändert da ich einmal die STUN Server geändert habe und nun noch einen Tippfehler gefunden habe.

      1) Wurde 127.0.0.1:180 in der .env gesetzt? Ansonsten kann Nginx nichts finden
      2) laufen die Container auch? „docker ps“
      3) Die Containernamen sind anders, der Schritt „mv docker-jitsi-meet/ jitsi-meet/“ muss ausgeführt werden
      4) Das restart.sh Script greift auf den Ordner jitsi-meet zu, dazu musste der Ordner umbenannt werden „cd $DOCKERPATH/jitsi-meet“

      Um schneller helfen zu können schau einfach in https://adminforge.de/chat/ vorbei.

    • Avatar Andi sagt:

      Moin, hast du da mittlerweile was hinbekommen? Hab das gleiche Problem :X die nginx-errorlogs sagen bei mir was von connection refused [error] 213#213: *4225 connect() failed (111: Connection refused) while connecting to upstream, client: 92.117.114.229, server: domain.de, request: „GET /favicon.ico HTTP/2.0“, upstream: „http://127.0.0.1:180/favicon.ico“, host: „domain.de“

      • Dominion Dominion sagt:

        Hallo Andi,

        ich hoffe du hast nicht wirklich domain.de in der Nginx Konfiguration stehen? 😉
        Dort bitte die eigene überall eintragen.

        Gruß

        • Avatar Andi sagt:

          Heyho, danke für die Antwort, war natürlich nur exemplarisch. Habe mittlerweile mein Problem ergründet. Ich verwende auf meinem Server das PaaS-System CapRover, welches recht cool und praktisch ist. Leider stresst da das Jitsi-Deploy rum (jvb möchte keine Verbindungen aufbauen) weshalb ich versucht hab, jitsi über docker-compose zu deployen. habe nun herausgefunden, dass der connection refused-Fehler durch die network-Einstellungen in docker-compose entstanden ist. CapRover nutzt docker und ein eigenes network für die Kommunikation der Dienste untereinander. Hab dann im Docker-Compose-File für Jitsi noch das externe Netzwerk hinzugefügt und schwupps hat alles funktioniert. Schon ganz interessant das Ganze aber die Komplexität ist wohl nicht zu unterschätzen 😀 Beste Grüße

        • Avatar Andi sagt:

          Ok noch ein kurzes Update: Funktioniert hat das ganze nun mit der Verison 4416, wenn ich die latest builds nehme bekomme ich wieder ein 502 und der jitsi meldet ein „no route to host“. So ein Krampf mit diesem Jitsi 😀

  9. Avatar Jo sagt:

    Bin leider netzwerk-seitig etwas schwach auf der Brust. Anknüpfend an die Frage von Kultex: wenn ich ein Testszenario mit Ubuntu-Hyper-V-VMs nur innerhalb eines abgeschotteten LANs aufbauen möchte, funktioniert die Anleitung auch dafür? Welche Schritte kann bzw. muss ich dabei weglassen?
    Ein erster Versuch geht natürlich bei der SSL-Zertifizierung schief. Der nginx-Check und -Restart bringt folglich auch Fehler.
    Grüße

    • Dominion Dominion sagt:

      Hallo Jo,

      richtig, genau sowas müsstest du weg lassen oder besser noch auf ein selbst signiertes SSL Zertifikat setzen.
      Dann werden die Browser aber sich beschweren. ZUm Test kannst du ja auch erstmal ohne SSL arbeiten.

      Gruß
      Dominion

  10. Avatar Wolfram sagt:

    Hallo Dominion,

    ich habe Probleme bei der Anlage von usern. Ich gehe gemäß der Anleitung auf https://community.jitsi.org/t/docker-authentication/39060/4 vor :

    prosodyctl –config /config/prosody.cfg.lua register TheDesiredUsername meet.jitsi TheDesiredPassword

    Dann scheitert der Befehl am Hostnamen. Ich gebe die öffentlich Adresse ein, jedoch ist der Hostname für proody der Name des Containers. Und damit scheitert der Befehl, wenn ich die öffentlice Adresse angeben. Mit Rechnernamensangebe des betreffenden Containers passiert gar nichts.

    Aus diesem grunde kann ich derzeit die Atuhentifizierung nicht nutzen.

    Freundiche Grüße
    Wolfram

  11. Avatar Wolfram sagt:

    Hallo Dominion,

    ich verstehe nicht, warum .jitsi-meet-cfg gelöscht werden muß. Das stellt nämlich im Zusammenhang mit der Authentifizierung ein Problem dar. In meinem Testlauf gestern waren nach Löschen dieses Verzeichnisses die User (noch waren es nur 3) verschwunden.
    Das hätte zur Folge, daß bei einer Änderung in .env die User neu angelegt werden müßten.
    Ich habe nicht den Eindruck, daß an Deiner Anleitung etwas fehlerhaft oder unvollständig -im Gegenteil ich finde sie weit mehr als hervorragend- ist.
    Ist es so schädlich, die config zu behalten? Falls ich das Prinzip der volumes verstanden habe, könnte man nicht die Config-Files „auslagern“ und persistent bleibend bearbeiten?
    Hast Du da vielleicht eine Idee?
    Ich werde auch nochmals forschen und Ergebnisse hier mitteilen.

    Freundliche Grüße
    Wolfram

    • Dominion Dominion sagt:

      Hallo Wolfram,

      das ist vollkommen richtig, wenn man Authentifizierung aktiv. Im Tutorial beschreibe ich jedoch eine öffentliche Instanz ohne Benutzerverwaltung!
      Der Ordner muss gelöscht werden da ansonsten die Änderungen in der .env nicht übernommen werden.
      Du kannst dir die .dat Dateien mit den Benutzern ja vorher weg kopieren und nach dem Update wieder an die selbe Stelle zurück kopieren.

      Gruß
      Dominion

Schreibe einen Kommentar

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