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:

Etherpad URL setzen, um gemeinsam an Dokumenten arbeiten zu können:

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 …

35 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.

    • Dominion Dominion sagt:

      Natürlich kann man auch die offizielle Debian/Ubuntu Anleitung befolgen: https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md
      Die einfache Docker Quick Install ist auch sehr kurz: https://github.com/jitsi/docker-jitsi-meet#quick-start

      Aber hier möchte ich ja ein wenig mehr beschreiben als nur eine Schnellinstallation.

      • Avatar Markus sagt:

        Hi Dominion,

        habe gestern das ganze der Anleitung nach installiert. Ich mag Docker, allerdings greift mir die Lösung hier zu kurz, da man dennoch am Hostsystem konfigurieren muss. Eine reine Dockerlösung wäre dann wahrscheinlich einfacher zu nutzen als das Kochrezept von Dir – was im übrigen Klasse ist und mir den schnellen Einstiegt erst ermöglicht hat – Danke. Ich werde aber evtl. auf die klassische Methode schwenken, da ich die Benutzerverwaltung mit prosody nutzen möchte und ich mich sonst zu sehr einarbeiten müsste. Würde aber wenn Du Interesse mit Dir zusammen das ganze auf das nächste Level heben. 1. Nginx in den Docker Container. 2.) Basis Config via Key/Value Paaren in der docker-compose.yml 3) Automatische Konfiguration der Docker Container inkl. letsencrypt setup. -> Ziel „apt get install docker; #get docker-compose.yml; #set ENV Key/values in docker-compose.yml; docker-compose up -d“. Mail mir wenn Du interesse hast. Vielen Dank jedenfalls für diesen super Artikel. Markus

  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 😀

      • Avatar Klaus sagt:

        Hallo, ich hänge hier auch an diesem Punkt fest. Selbst ein lokales w3m http://127.0.0.1:180 läuft in ein Timeout. Irgendwie scheint Docker die Portweiterleitungen nicht richtig einzurichten.

  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

  12. Avatar Holger sagt:

    Hi!

    Kleiner Hinweis: ich wollte aus Gründen xmpp-websocket aktivieren und dafür musste ich in der „location /“ noch folgendes ergänzen, da sonst die Verbindungsanforderung an den Websocket schief läuft:

    proxy_http_version 1.1;
    proxy_set_header Connection „upgrade“;
    proxy_set_header Upgrade \$http_upgrade;
    tcp_nodelay on;

    Da dieser PR (https://github.com/jitsi/docker-jitsi-meet/pull/502) gemergt wurde, dachte ich, ich sags mal. Nur für den Fall, das kommt unerwartet in einem nächsten Docker Image Release und jemand läuft dann mit der Beschreibung hier vor das gleiche Problem, wie ich 🙂

    LG
    Holger

  13. Avatar Chris sagt:

    Super Anleitung, danke. Was mich in Richtung STUN/Turn interessieren würde: Es gibt in der Config zwar einen Parameter für den Discovery-Server, gibt es aber auch etwas in Richtung Shared Secret für diesen Server? Betreibe einen eigenen Server, der ist aber nicht public…

    Zweite Frage: Was hat es denn mit XMPP_BOSH_URL_BASE=http://xmpp.meet.jitsi:5280 auf sich? Das steht in der Config default und wird nicht behandelt? Ist das für irgendeine Federation?

    Gruß
    Chris

    • Dominion Dominion sagt:

      Hallo Chris,

      es gibt „turncredentials_secret“ was original in der „turn.cfg.lua“ konfiguriert wird. Für Docker benötigst du noch das mod_turncredentials.lua Prosody Modul.
      Ich habe es bei meet.adminforge.de aktiv, aber noch nicht getestet ob es auch korrekt funktioniert. Die Docker Version soll ja TURN bekommen, da würde ich noch abwarten.

      Der BOSH Port 5280 lauscht ja nur auf dem internen Netzwerk und wird nicht fürs föderieren genutzt.

      Gruß
      Dominion

Schreibe einen Kommentar

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