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/Debian 11 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.example.com oder teamjoin.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:
1 | apt-get update && apt-get install -y ca-certificates curl gnupg lsb-release git |
GPG Key herunterladen:
1 | curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg |
Repository hinzufügen Ubuntu:
1 2 3 | echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null |
Repository hinzufügen Debian:
1 2 3 | echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian \ $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null |
Docker CE installieren:
1 | apt-get update && apt-get -y install docker-ce docker-ce-cli containerd.io |
Die aktuellste Docker Compose Version installieren wir mit diesem Befehl:
1 | curl -L "https://github.com/docker/compose/releases/download/$(curl -s https://github.com/docker/compose/releases/latest | cut -d "/" -f8 | cut -d "\"" -f1)/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose; chmod +x /usr/local/bin/docker-compose |
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:
1 | mkdir /opt/docker |
Wir wechseln in den Ordner und klonen das Git Repository:
1 2 | cd /opt/docker git clone https://github.com/jitsi/docker-jitsi-meet.git |
Nun wechseln wir in diesen Ordner und kopieren die .env Konfigurationsdatei:
1 2 3 | mv docker-jitsi-meet/ jitsi-meet/ cd jitsi-meet/ cp env.example .env |
Jetzt erstellen wir sichere Passwörter mit dem vorhandenen Script:
1 | ./gen-passwords.sh |
Die Konfigurationsordner in unserem Verzeichnis .jitsi-meet-cfg müssen wir manuell erstellen:
1 | mkdir -p .jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb,jigasi,jibri} |
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:
1 2 | # Directory where all configuration will be stored CONFIG=.jitsi-meet-cfg |
Da wir später unseren Nginx Proxy vorschalten stellen wir die HTTP Ports von Jitsi Meet auf localhost um:
1 2 3 4 5 | # Exposed HTTP port HTTP_PORT=127.0.0.1:180 # Exposed HTTPS port HTTPS_PORT=127.0.0.1:1443 |
Nun estellt die Timezone in Deutschland auf Europe/Berlin:
1 2 | # System time zone TZ=Europe/Berlin |
Nun tragen wir die (Sub)domain die wir für diese Jitsi Meet Instanz verwenden möchten ein:
1 2 | # Public URL for the web service PUBLIC_URL=https://meet.example.com |
Einschalten von ein paar nützlichen Funktionen:
1 2 3 4 5 6 7 8 | # Control whether the lobby feature should be enabled or not ENABLE_LOBBY=1 # Show a prejoin page before entering a conference ENABLE_PREJOIN_PAGE=1 # Enable breakout rooms ENABLE_BREAKOUT_ROOMS=1 |
Etherpad URL setzen, um gemeinsam an Dokumenten arbeiten zu können:
1 2 | # Set etherpad-lite public URL (uncomment to enable) ETHERPAD_PUBLIC_URL=https://pad.adminforge.de/p/ |
Damit alles reibungslos läuft, tragen wir die Docker Host IP-Adresse ein:
1 2 | # Public IP address JVB_ADVERTISE_IPS=< PUBLIC-IP-ADDRESS > |
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:
1 2 | # STUN servers used to discover the server's public IP JVB_STUN_SERVERS=relay.adminforge.de:443,relay2.adminforge.de:443 |
Damit nicht die unstable Version genutzt wird forcieren wir stable:
1 | JITSI_IMAGE_VERSION=stable |
Punkt 4: Nginx Port 80 vHost erstellen
Nginx installieren.
1 | apt install nginx |
Wir wechseln in den Nginx vHost Ordner.
1 | cd /etc/nginx/sites-available/ |
Nun erstellen wir einen Port 80 vHost für Let’s Encrypt und zur Weiterleitung an HTTPS.
1 2 3 4 5 6 7 8 9 10 11 12 13 | server { listen 80; listen [::]:80; server_name meet.example.com; location /.well-known/acme-challenge { root /var/www/letsencrypt; default_type "text/plain"; try_files $uri =404; } location / { return 301 https://$host$request_uri; } } |
Wir aktivieren die Konfiguration.
1 | ln -s /etc/nginx/sites-available/meet.example.com.conf /etc/nginx/sites-enabled/meet.example.com.conf |
Nun laden wir die Konfiguration.
1 | systemctl reload nginx.service |
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:
1 2 3 4 5 | apt install -y socat curl https://get.acme.sh | sh source .bashrc acme.sh --set-default-ca --server letsencrypt acme.sh --set-default-chain --preferred-chain "ISRG" --server letsencrypt |
1 2 3 | ... CERT_HOME="/etc/ssl/private" ... |
1 2 3 | mkdir /etc/nginx/global mkdir /var/www/letsencrypt chown www-data. /var/www/letsencrypt -R |
1 | acme.sh --issue -k ec-384 -w /var/www/letsencrypt -d meet.example.com --reloadcmd "systemctl reload nginx.service" |
1 | openssl dhparam -out /etc/nginx/dhparams.pem 4096 |
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!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 | server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name meet.example.com; access_log off; error_log /var/log/nginx/meet.example.com.error.log; ssl_certificate /etc/ssl/private/meet.example.com_ecc/fullchain.cer; ssl_certificate_key /etc/ssl/private/meet.example.com_ecc/meet.example.com.key; ssl_dhparam /etc/nginx/dhparams.pem; ssl_buffer_size 1400; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; ssl_protocols TLSv1.2 TLSv1.3; # Ab Nginx 1.15.4 # ssl_early_data on; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers on; ssl_stapling on; ssl_stapling_verify on; ssl_ecdh_curve X25519:P-384:P-256:P-521; resolver 176.9.93.198 176.9.1.117 valid=300s; resolver_timeout 5s; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"; add_header X-Xss-Protection "1; mode=block"; add_header X-Content-Type-Options nosniff; add_header Referrer-Policy same-origin; proxy_cookie_path / "/; HTTPOnly; Secure"; add_header Expect-CT "enforce, max-age=21600"; add_header Feature-Policy "payment none"; keepalive_timeout 70; sendfile on; client_max_body_size 0; gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; location / { log_not_found off; proxy_cache_valid 200 120m; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Scheme $scheme; proxy_pass http://127.0.0.1:180/; } location ~ ^/colibri-ws/([a-zA-Z0-9-\.]+)/(.*) { tcp_nodelay on; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_pass http://127.0.0.1:180/colibri-ws/$1/$2$is_args$args; } location /xmpp-websocket { tcp_nodelay on; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_pass http://127.0.0.1:180/xmpp-websocket; } } |
Wenn alles angepasst ist erstellen wir den Symlink, ersetzt hier auch wieder meet.example.com:
1 | ln -s /etc/nginx/sites-available/meet.example.com_ssl.conf /etc/nginx/sites-enabled/meet.example.com_ssl.conf |
Jetzt prüfen wir ob alles korrekt ist un laden Nginx Konfigurationen neu:
1 2 3 | nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful |
1 | systemctl reload nginx.service |
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:
1 | docker-compose up -d |
Ob alles läuft prüfen wir mit diesem Befehl:
1 2 3 4 5 6 | docker-compose ps NAME COMMAND SERVICE STATUS PORTS jitsi-meet-jicofo-1 "/init" jicofo running jitsi-meet-jvb-1 "/init" jvb running 0.0.0.0:4443->4443/tcp, 0.0.0.0:10000->10000/udp, :::4443->4443/tcp, :::10000->10000/udp jitsi-meet-prosody-1 "/init" prosody running 5347/tcp jitsi-meet-web-1 "/init" web running 127.0.0.1:180->80/tcp, 127.0.0.1:1443->443/tcp |
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!
1 2 3 4 | docker-compose down rm -r .jitsi-meet-cfg mkdir -p .jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb,jigasi,jibri} docker-compose up -d |
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
 Das Betreiben der Dienste, Webseite und Server machen wir gerne, kostet aber leider auch Geld.Unterstütze unsere Arbeit mit einer Spende. |
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.
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.
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
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!
Die Anleitung habe ich angepasst. Schau mal ob es so verständlicher ist.
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!
Interessant, welche Nginx Version nutzt du?
Entferne mal die Zeile in der vHost Config mit
ssl_early_datassl_early_data löschen hat geholfen, jetzt läuft alles. Danke!
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.
Mhh docker-compose startet beim Boot alles was vorher aktiv war automatisch.
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
Es reicht aus diese externen Ports freizugeben:
80/tcp
443/tcp
4443/tcp
10000/udp
Geniale Anleitung, alles hat so funktioniert wie es hier beschrieben war. Wer möchte kann meinen Jitsi Server gern verwenden.
https://meet.blankenberg.eu
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?
Hi,
du meinst wegen 480p Einstellung bei dir?
Hast du mal mit dieser 480p Instanz verglichen https://www.kuketz-meet.de/ ? Oder meiner https://meet.adminforge.de/ ?
Gruß
Hi,
auch dort tritt es auf. Auch mit unterschiedlichen Geräten. Aber immer nur über Chrome. Auf dem Smartphone auch, wenn der Chrome im Desktopmodus läuft.
Gruß
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ß
Hatte ich noch nichts versucht, wenn es Docker für den Pi gibt sollte es gehen ja. Auch ohne Internet dann.
sollte mit armbian möglich sein – https://github.com/armbian/config – es wird Docker (Docker CE engine) installiert…
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?
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.
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“
Hallo Andi,
ich hoffe du hast nicht wirklich domain.de in der Nginx Konfiguration stehen? 😉
Dort bitte die eigene überall eintragen.
Gruß
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
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 😀
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.
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
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
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
Hallo Wolfram,
du hast es anscheinend gelöst bei dir? Kannst du uns bitte erhellen? 😉
Gruß
Dominion
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
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
Hallo Dominion,
kannst du eventuell etwas ausführen, welche Docker-Mechanismen greifen, dass der Ordner gelöscht werden muss? Der Ordner wird doch nur als Docker-Volume gemountet. Ich bin ziemlich neu mit Docker und verstehe nicht ganz, wieso die .env erst neu eingelesen wird, wenn der Ordner fehlt. Laut einer anderen Quelle macht Docker das automatisch. Danke dir im Voraus!
Grüße,
David
Hallo David,
also so war es zumindest als ich die Anleitung geschrieben habe:
– Wenn .jitsi-meet-cfg existiert, liest er nicht die .env neu ein.
– Wenn .jitsi-meet-cfg gelöscht wurde, erstellt er die Ordnerstruktur und Configs neu – liest somit die .env wieder ein um neue Configs zu erstellen.
Gruß
Dominion
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
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
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
habe mit Interesse den Beitrag gelesen. Wie kann man denn das Ganze in einem unter Plesk installierten Docker-Container realisieren? Irgendwie stehe ich da völlig auf dem Schlauch. Kennt jemand ein vernünftiges HowTo für das Szenario? Via Google ist nicht wirklich was brauchbares zu finden.
Hallo, danke für die ausführliche Anleitung. Alles in allem bin ich zu einem funktionierenden ViKo-System gekommen, allerdings mit einer Einschränkung: Auf einem teilnehmenden System in einem abgeschotteten Firmennetzwerk wird keine Videoverbindung aufgebaut (10000/udp blockiert). Ich habe schon ein wenig gegoogelt und meine, die Lösung in der Notwendigkeit eines eigenen Coturn-Servers ausgemacht zu haben. Ich hätte sogar Zugriff auf einen. Macht es grundsätzlich Sinn, in diese Richtung weiter zu forschen oder gibt es ggf. einen sinnvolleren Ansatz?
Korrekt, Turn ist da genau der richtige Ansatz und den kannst du weiter verfolgen.
Hallo, danke für die Anleitung!
Leider klappt das nicht (mehr) so wie beschrieben.
Ich hab mehrere Probleme, die ein erfolgreichen Verbindungsaufbau verhindern.
Die aller neuste Version, welche man per git bekommt, ist wohl defekt.
Die Container lassen sich nicht sauber starten und der Log haut nur irgendwelche Nonsense-Java-Fehler raus.
Mit dem Release stable-5390-3 funktioniert immerhin der Startvorgang sauber.
Ich kann ein Meeting mit Teilnehmern im gleichen Netzwerk starten (also z.B. im LAN).
Sobald ein Teilnehmer aus einem anderen Netz dazu kommt, kann er dem Meeting beitreten, Video und Audio-Chat gehen aber dann nicht.
Das eine Problem ist, das man jetzt auch intern alles via HTTPS durchleiten muss.
Die nginx-Config habe ich daher so angepasst, dass die HTTPS-Ports genutzt werden.
Das Problem hatte ich bei einem anderen Fall letztens schon einmal (andere Software, aber gleiches Phänomen) und konnte es so direkt lösen.
Das kein gültiges Zertifikat hinterlegt ist, ist nicht schlimm. Geht trotzdem.
Beim Verbindungsaufbau kommt aber nun folgendes Problem:
Firefox meldet das hier:
2021-04-10T19:31:55.825Z [modules/connectivity/ParticipantConnectionStatus.js] : Detector RTCEvents.ENDPOINT_CONN_STATUS_CHANGED(1618083115825): ed7816c6: false Logger.js:154:22
2021-04-10T19:31:55.825Z [modules/connectivity/ParticipantConnectionStatus.js] : Figure out conn status for ed7816c6, is video muted: false is active(jvb): false video track frozen: false p2p mode: false is in last N: true currentStatus => newStatus: interrupted => interrupted Logger.js:154:22
2021-04-10T19:31:56.326Z [modules/RTC/BridgeChannel.js] : Endpoint connection status changed: ed7816c6 active=false Logger.js:154:22
Der Docker-Log gibt folgendes aus:
web_1 | 172.21.0.1 – – [10/Apr/2021:21:32:09 +0200] „POST /http-bind?room=test123 HTTP/1.0“ 200 318 „-“ „okhttp/3.12.1“
jvb_1 | Apr 10, 2021 9:32:12 PM org.jitsi.utils.logging2.LoggerImpl log
jvb_1 | INFO: Performed a successful health check in PT0S. Sticky failure: false
Ich habe jetzt 8 Stunden mit Internetsuche und Probieren verbracht, aber nichts hilft.
Aktuell nervt das Zeugs einfach nur noch.
Hast du eine Idee, woran das liegen könnte?
Hallo Hoerli,
also die stable-5390-3 ist auch noch die aktuellste Version. Container lasse ich in der Anleitung nicht bauen.
Dein Problem klingt sehr stark nach fehlender PUBLIC_URL Konfiguration, hast du die Variable gesetzt?
Du kannst mal im Browser in die F12 Konsole schauen welche Fehler dort auftreten.
Gerne auch hier weiter diskutieren: https://community.adminforge.de/
Gruß
Dominion
Hallo Hoerli,
ich habe das Problem gerade selbst feststellen können.
Die
docker-compose.ymlund.envaus dem git Master Branch sind zu neu für „stable-5390-3“, welche noch als latest getagged ist.Wenn du die beiden Dateien aus dem Release Source Code nimmst startet auch alles normal: https://github.com/jitsi/docker-jitsi-meet/releases
Ich vermute es liegt an dem neuen OCTO was vor ein paar Tagen eingebaut wurde.
Gruß
Dominion
Hallo Zusammen,
ich würde gerne die Breakout Rooms aktivieren. Ich weiß aber nicht wie ich das im Docker Umfeld aktivieren kann. Meine yml Datei habe ich angepasst. Muss ich in meiner .env Datei noch diese aktivieren?
Vielen Dank
Hi,
die Breakout Rooms scheinen gerade neu in der jitsi-meet version 2.0.6689 gekommen zu sein -> https://github.com/jitsi/jitsi-meet/releases
Es dauert somit noch bis zum nächsten docker-jitsi-meet release, du kannst es hier verfolgen -> https://github.com/jitsi/docker-jitsi-meet/releases
Gruß
Dominion
Hello,
I have followed the complete guide and set up my server as well but my jitsi is too slow I don’t know why, when I click join meeting it takes too much time.