Videokonferenzen werden heutzutage immer wichtiger. Im geschäftlichen Umfeld kommen hier meist proprietäre Lösungen wie z.B. Skype zum Einsatz. In Sachen Datenschutz und Privatsphäre sind diese Lösungen natürlich bedenklich.
Die bessere Alternative kann hier Jitsi Meet sein. Dies ist eine quelloffene Software, mit der Videokonferenzen mit mehreren Teilnehmern durchgeführt werden können.
Der folgende Artikel zeigt die Installation und Konfiguration von Jitsi Meet unter Ubuntu Server mit nginx als Webserver. Ebenso kommt coturn als eigener TURN-/STUN-Server zum Einsatz.
Update-Historie (letztes Update: 17.09.2021)- 17.09.2021:
- Anleitung basiert nun auf Ubuntu 20.04..
- Optional: Nutzung der offiziellen Prosody-Paketquellen (für Ubuntu 18.04 erforderlich).
- 31.08.2020:
- Update vHost für Jitsi Meet.
- 30.03.2021:
- Anpassungen virtueller Host (nginx) für Jitsi Meet.
- 31.08.2020:
- Update vHost für Jitsi Meet.
- 02.05.2020:
- Einbindung eines eigenen coturn-Servers verbessert (useStunTurn).
- Hinweis zum Deaktivieren der Verbindungen zu externen Diensten ergänzt.
- 05.04.2020:
- Artikel nochmals auf die aktuellste Jitsi Meet Version angepasst.
- coturn wird nun als TURN-/STUN-Server für Jitsi Meet integriert.
- 03.04.2020:
- Artikel überarbeitet, da sich nach dem letzten Update von Jitsi Meet einiges geändert hat.
- 28.03.2020:
- Weitere Hinweise zur Verwendung eines eigenen STUN-Servers (coturn) hinzugefügt.
Inhalt
Voraussetzungen/Ziele
Zum Thema Jitsi Meet gibt es bereits unzählige Tutorials im Netz. Diese beziehen sich aber meist nur auf die Standard-Installation und es wird meist auch nicht explizit auf die Webserver-Konfiguration eingegangen. Das Augenmerk auf die (sichere) Webserver-Konfiguration ist meiner Meinung allerdings sehr wichtig, v.a. wenn auf dem Server bereits andere Anwendungen gehostet werden.
Darüber hinaus schlägt die Installation unter Ubuntu Server 20.04 u.U. manchmal fehl. Hier gilt es dann einige Besonderheiten zu beachten.
Dabei kommen folgende Programm-Versionen zum Einsatz:
- Ubuntu Server 20.04 LTS („Focal Fossa“).
- nginx 1.21.3 (aktuelle Mainline-Version).
- coturn 4.5.0.7.
Dieses Tutorial konzentriert sich dabei v.a. auf Jitsi Meet. Eine komplette Beschreibung der Webserver-Konfiguration (nginx, Let’s Encrypt/acme.sh) würde sicherlich den Rahmen des Artikel sprengen.
Wichtig: nginx muss vor der Installation von Jitsi Meet bereits auf dem System vorhanden sein, da das Jitsi-Setup darauf aufbaut und virtuelle Hosts anlegt.
Ich gehe im folgenden davon aus, dass auf dem System nginx bereits installiert und eingerichtet ist. Ebenfalls sollte alles vorbereitet sein, dass TLS-Zertifikate über Let’s Encrypt ausgestellt werden können.
Wie eine entsprechende Konfiguration (nginx/Let’s Encrypt) aussehen kann wird in folgenden Artikel näher beschrieben:
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
- TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
Ebenso wird eine bereits laufende Instanz von coturn (TURN-/STUN-Server) vorausgesetzt. Die dies umgesetzt werden kann, ist im Artikel Nextcloud Talk mit eigenem TURN-Server (coturn) beschrieben.
Im Rahmen des Tutorials nutze ich folgende beispielhafte Domains:
- meet.meinedomain.de für die Jitsi Meet Installation.
- turn.meinedomain.de für die coturn-Instanz.
Systemvoraussetzungen
Jitsi Meet hat moderate Systemvoraussetzungen, was CPU/RAM angeht. Logischerweise sind die Anforderungen bzgl. der Bandbreite (Up- bzw. Download) für eine Videokonferenz-Lösung recht hoch. Dies hängt allerdings stark von der erwarteten Nutzung (= Anzahl der parallel zugreifenden Teilnehmer) des Jitsi Meet Servers ab.
Trotzdem sollte man sich an einem privaten Internet-Anschluss nicht all zu viele Hoffnungen machen. Auch bei einer guten Bandbreite des Internet-Anschlusses wird man hier bei einer selbstgehosteten Lösung in den eigenen vier Wänden nur Konferenzen mit wenigen Teilnehmern durchführen können. Im Allgemeinen ist daher die Empfehlung, Jitsi Meet auf einem eigenen Root-Server zu betreiben. Aus eigener Erfahrung kann ich hier einen Server von Netcup (Affiliate-Link) empfehlen.
Vor der Installation zu beachten
Jitsi Meet besteht aus einer Reihe von Komponenten, die im Rahmen des Setups installiert werden.
Wenn auf dem Server bereits Teile dieser Komponenten installiert sind, besteht die Gefahr, dass bereits laufende Systeme unbrauchbar werden, da Jitsi Meet einfach die bestehenden Komponenten/Konfiguration überschreibt.
Dies betrifft zum einen coturn, als auch Prosody.
Die Beschreibungen in diesem Artikel sorgen dafür, dass ein vorhandener coturn Server nicht überschrieben wird.
Allerdings sollte das Jitsi Meet Setup nicht ausgeführt werden, wenn bereits ein Prosody/XMPP Server auf dem System betrieben wird.
Vorbereitungen
Nun kann es auch schon an die Installation gehen.
Betriebssystem-Updates
Vor der eigentlichen Installation wird das System zunächst auf den neusten Stand gebracht:
apt update && apt upgrade -V && apt dist-upgrade && apt autoremove reboot
Anpassungen nginx
Wichtig: nginx ist meistens so konfiguriert, dass die virtuellen Hosts unter /etc/nginx/conf.d geladen werden. Das Setup von Jitsi Meet geht allerdings davon aus, dass die virtuellen Hosts unter /etc/nginx/sites-available bzw. /etc/nginx/sites-enabled zu finden sind. Daher müssen diese Verzeichnisse manuell angelegt werden, falls diese noch nicht vorhanden sind (dies betrifft darüber hinaus auch noch ein drittes Verzeichnis):
mkdir -p /etc/nginx/sites-available mkdir -p /etc/nginx/sites-enabled mkdir -p /etc/nginx/modules-enabled
Wird dieser Schritt nicht ausgeführt, schlägt das Setup von Jitsi Meet später fehl!
Domain/TLS-Zertifikate
Wie bereits erwähnt, nutzen wir für den Artikel die fiktive (Sub-)Domain meet.meinedomain.de.
Für diese Domain sollten vor dem Jitsi-Setup bereits Zertifikate über Let’s Encrypt beantragt werden. Folgende Artikel sollten dazu einen guten Anhaltspunkt geben:
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
- TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
Die folgende Konfiguration wird RSA- und ECDSA-Zertifikate (Hybrid-Betrieb) mit TLSv1.2/TLSv1.3 nutzen.
Auflösung der Domain auf localhost
Auf dem Server, auf dem Jitsi Meet installiert werden soll, muss die verwendete Domain auf localhost auflösen. Dies wird in der Hosts-Datei konfiguriert:
nano /etc/hosts
Ganz unten wird nun folgender Eintrag hinzugefügt:
127.0.0.1 meet.meinedomain.de
Optional: Offizielle Prosody Paketquellen nutzen
Dieser Schritt ist unter Ubuntu 20.04 optional, sorgt aber dafür, dass Prosody aus den offiziellen Prosody-Paketquellen genutzt wird. Diese Versionen sind meist wesentlich aktueller als die Versionen aus den Ubuntu-Paketquellen.
Wichtig: Unter älteren Ubuntu-Versionen (z.B. 18.04) ist dieser Schritt nicht optional, da Prosody in einer zu alten Version enthalten ist.
Zunächst werden die Paketquellen selbst hinzugefügt:
echo "deb http://packages.prosody.im/debian $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/prosody.list"
Anschließend wird noch der Key des Repositories auf dem System bekannt gemacht:
wget https://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add -
Installation Jitsi Meet
Als nächstes kann es an die eigentliche Installation von Jitsi Meet gehen.
Jitsi Meet – Setup
Da das Programm (noch) nicht in den offiziellen Ubuntu Paketquellen enthalten ist, müssen wir das Repository zunächst einbinden.
Dazu wird als erstes der Repository-Key im System importiert:
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
Anschließend kann das Repository eingebunden werden:
echo 'deb https://download.jitsi.org stable/' >> /etc/apt/sources.list.d/jitsi-stable.list
Nun werden die Paketquellen noch aktualisiert:
apt update
Es folgt die eigentliche Installation.
Wichtig ist hierbei die Angabe von no-install-recommends, da ansonsten u.a. die Konfiguration von coturn überschrieben wird.
apt install --no-install-recommends jitsi-meet
Während der Installation wird man zuerst nach der Domain gefragt, unter der Jitsi Meet gehostet werden soll. Dies ist die Domain, für das vorher schon das TLS-Zertifikat ausgestellt wurde – in diesem Beispiel also meet.meinedomain.de.
Als nächstes wird noch nach dem Zertifikat gefragt: Hier muss die zweite Option gewählt werden (I want to use my own certificate), da wir die Zertifikate selbst verwalten wollen (siehe oben).
Nun wird man noch nach dem Speicherort der Zertifikats-Dateien gefragt. Diese beiden Dialoge (einmal für die *.key und einmal für die *crt-Datei) kann einfach mit OK bestätigt werden. Die Zertifikate werden im Anschluss manuell im virtuellen Host von nginx hinzugefügt.
Das Setup sollte anschließend ohne Probleme durchlaufen.
Jitsi Meet – Anpassen des virtuellen Hosts (nginx)
Das Setup hat nun im Verzeichnis /etc/nginx/sites-available einen neuen virtuellen Host erstellt und einen symbolischen Link in /etc/nginx/sites-enabled hinzugefügt. Da wir an dieser Stelle die Verzeichnisse sites-availabe und sites-enabled nicht verwenden, wird die Datei hier entfernt und in das passende Verzeichnis verschoben:
rm /etc/nginx/sites-enabled/meet.meinedomain.de.conf mv /etc/nginx/sites-available/meet.meinedomain.de.conf /etc/nginx/conf.d/meet.meinedomain.de.conf
Den Webserver noch nicht neu starten, erst bedarf es noch Anpassungen am vHost für Jitsi Meet.
nano /etc/nginx/conf.d/meet.meinedomain.de.conf
Diese Datei wird nun folgendermaßen erweitert:
server_names_hash_bucket_size 64;
#server {
# listen 80;
# server_name meet.meinedomain.de;
# return 301 https://$host$request_uri;
#}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name meet.meinedomain.de;
#
# SSL configuration
#
# RSA certificates
ssl_certificate /etc/letsencrypt/meet.meinedomain.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meet.meinedomain.de/rsa/key.pem;
# ECC certificates
ssl_certificate /etc/letsencrypt/meet.meinedomain.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meet.meinedomain.de/ecc/key.pem;
# This should be ca.pem (certificate with the additional intermediate certifica$
# See here: https://certbot.eff.org/docs/using.html
# ECC
ssl_trusted_certificate /etc/letsencrypt/meet.meinedomain.de/ecc/ca.pem;
# SSL stapling has to be done seperately, becuase it will not work with self signed certs
# OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;
# Not using TLSv1 will break:
# Android <= 4.4.40 IE <= 10 IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
ssl_protocols TLSv1.2 TLSv1.3;
# SSL ciphers: RSA + ECDSA
# Two certificate types (ECDSA, RSA) are needed.
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';
# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;
# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;
# Add your DNS resolver here
resolver 192.168.178.1;
# SSL session handling
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
#
# Headers
#
# HSTS (ngx_http_headers_module is required) In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Robots-Tag none always;
add_header X-Download-Options noopen always;
add_header X-Permitted-Cross-Domain-Policies none always;
add_header Referrer-Policy no-referrer always;
#add_header X-Frame-Options "SAMEORIGIN" always;
# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;
root /usr/share/jitsi-meet;
# ssi on with javascript for multidomain variables in config.js
ssi on;
ssi_types application/x-javascript application/javascript;
index index.html index.htm;
error_page 404 /static/404.html;
gzip on;
gzip_types text/plain text/css application/javascript application/json image/x-icon application/octet-stream application/wasm;
gzip_vary on;
gzip_proxied no-cache no-store private expired auth;
gzip_min_length 512;
location = /config.js {
alias /etc/jitsi/meet/meet.meinedomain.de-config.js;
}
location = /external_api.js {
alias /usr/share/jitsi-meet/libs/external_api.min.js;
}
# ensure all static content can always be found first
location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
{
add_header 'Access-Control-Allow-Origin' '*';
alias /usr/share/jitsi-meet/$1/$2;
# cache all versioned files
if ($arg_v) {
expires 1y;
}
}
# BOSH
location = /http-bind {
proxy_pass http://localhost:5280/http-bind;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
}
# xmpp websockets
location = /xmpp-websocket {
proxy_pass http://127.0.0.1:5280/xmpp-websocket?prefix=$prefix&$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;
tcp_nodelay on;
}
# colibri (JVB) websockets for jvb1
location ~ ^/colibri-ws/default-id/(.*) {
proxy_pass http://127.0.0.1:9090/colibri-ws/default-id/$1$is_args$args;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
tcp_nodelay on;
}
location ~ ^/([^/?&:'"]+)$ {
try_files $uri @root_path;
}
location @root_path {
rewrite ^/(.*)$ / break;
}
location ~ ^/([^/?&:'"]+)/config.js$
{
set $subdomain "$1.";
set $subdir "$1/";
alias /etc/jitsi/meet/meet.meinedomain.de-config.js;
}
# Anything that didn't match above, and isn't a real file, assume it's a room name and redirect to /
location ~ ^/([^/?&:'"]+)/(.*)$ {
set $subdomain "$1.";
set $subdir "$1/";
rewrite ^/([^/?&:'"]+)/(.*)$ /$2;
}
# BOSH for subdomains
location ~ ^/([^/?&:'"]+)/http-bind {
set $subdomain "$1.";
set $subdir "$1/";
set $prefix "$1";
rewrite ^/(.*)$ /http-bind;
}
# websockets for subdomains
location ~ ^/([^/?&:'"]+)/xmpp-websocket {
set $subdomain "$1.";
set $subdir "$1/";
set $prefix "$1";
rewrite ^/(.*)$ /xmpp-websocket;
}
}Erklärungen zu den einzelnen Änderungen:
- Zunächst wird der virtuelle Host für HTTP (Port 80) deaktiviert/auskommentiert. Dieser wird nicht benötigt, da dieser schon in einer anderen Datei vorhanden ist (sonst hätte ja die Erzeugung der TLS-Zertifikate über Let’s Encrypt vorher nicht geklappt).
- Es folgen die Einstellungen für SSL. Die vom Jitsi Meet Setup eingefügten Zeilen wurden hier wieder auskommentiert und durch eigene optimierte Anweisungen ersetzt (RSA- und ECDSA-Zertifikate im Hybrid-Betrieb).
- Wichtig ist hier noch die Angabe eines (DNS-)Resolvers (resolver 192.168.178.1). Hier ist die IP-Adresse eines DNS-Servers anzugeben (in diesem Beispiel die IP-Adresse des Routers, da dieser als DNS-Server fungiert).
- Anschließend werden noch Header gesetzt, die für eine sichere Webserver-Konfiguration empfohlen sind.
- Weiter unten wurde noch ein weiterer location-Block hinzugefügt. Dieser sorgt dafür, dass die externe API von Jitsi Meet verfügbar ist. Dies wird zur Nutzung der Desktop-Clients/mobilen Apps von Jitsi Meet benötigt.
Nun wird der Webserver neu gestartet:
service nginx restart
Zum Schluss müssen ein paar benötigte Ports in der Firewall freigeschaltet werden (in diesem Beispiel nutze ich die Firewall ufw):
ufw allow http ufw allow https ufw allow in 10000/udp
Falls eine andere Firewall genutzt wird, ist diese entsprechend zu konfigurieren. Denkt auch daran, dass das Port-Forwarding ggf. auch im Router konfiguriert werden muss (Ports 80, 443, Protokoll: TCP und Port 10000, Protokoll: UDP).
Diese Ports müssen übrigens auch bei den Clients geöffnet sein (nur für ausgehenden Traffic!).
Konfiguration Jitsi Meet
Nach der Installation müssen noch einige Dinge an der Installation angepasst werden.
coturn als TURN-/STUN-Server
Jitsi Meet benötigt für einen stabilen Betrieb sowohl einen TURN-Server, als auch STUN-Server. Dies ist eine Technologie, die Verbindungen durch Router/Firewalls ermöglicht.
Als TURN-/STUN-Server nutze ich hier die quelloffene Implementierung coturn. Wie ein coturn-Server aufgesetzt werden kann, wurde bereits im Artikel Nextcloud Talk mit eigenem TURN-Server (coturn) beleuchtet.
Zunächst hinterlegen wir die Daten für TURN:
nano /etc/prosody/conf.d/meet.meinedomain.de.cfg.lua
Hier wird ziemlich weit oben der zu verwendende TURN-Server angegeben. Diese Konfiguration wird nun so abgeändert, dass die eigene coturn-Instanz genutzt wird:
turncredentials_secret = "my-secret";
turncredentials = {
{ type = "stun", host = "turn.meinedomain.de", port = "5349" },
{ type = "turn", host = "turn.meinedomain.de", port = "5349", transport = "udp" },
{ type = "turns", host = "turn.meinedomain.de", port = "5349", transport = "tcp" }
};Wichtig ist hier v.a. das sog. „Secret“, als auch die zu nutzenden Ports. Diese Konfiguration liegt jedoch nicht bei Jitsi Meet, sondern bei coturn selbst. Die Konfiguration von coturn befindet sich dabei hier: /etc/turnserver.conf (tls-listening-port und static-auth-secret).
Für STUN nutzt Jitsi in der Standard-Konfiguration einen eigenen Server (meet-jit-si-turnrelay.jitsi.net:443). Hier können aber auch beliebige andere STUN-Server genutzt werden.
Dazu wird einfach die entsprechende Konfiguration geöffnet:
nano /etc/jitsi/meet/meet.meinedomain.de-config.js
Hier sucht man nun nach der Stelle, an der die STUN-Server hinterlegt sind:
stunServers: [
{ urls: 'meet-jit-si-turnrelay.jitsi.net:443' }
],Hier können nun andere STUN-Server hinterlegt werden. Eine Liste mit öffentlichen STUN-Servern findet man z.B. hier.
Wir nutzen hier allerdings ebenfalls die eigene coturn-Instanz:
stunServers: [
{ urls: 'stun:stun.meinedomain.de:5349' }
],Damit nur noch der eigene TURN-/STUN-Server genutzt wird, ist noch eine Variable (useStunTurn) in dieser Konfigurations-Datei zu ändern:
p2p: {
# ...
useStunTurn: true,
# ...Nun werden alle Dienste nochmal neu gestartet, damit die Änderungen übernommen werden:
service prosody restart service jicofo restart service jitsi-videobridge2 restart
Test des eigenen STUN-Servers: Um den eigenen STUN-Server zu testen, kann diese Seite gnutzt werden. Unter STUN or TURN URI wir dann folgendes eingegeben: stun:stun.meinedomain.de:5349
Nach einem Klick auf Gather candidates sollte das Ergebnis dann in etwa so aussehen:
Wichtig sind dabei, dass die Einträge vom Typ „srflx“ angezeigt werden.
Öffentlichen Zugang unterbinden („Secure Domain“)
Jitsi Meet ist nun so konfiguriert, dass jeder, der die URL des Servers kennt, beliebig viele Konferenz-Räume erstellen kann. Dies ist u.U. nicht gewünscht, da man den Server z.B. nur privat verwenden möchte. In diesem Fall kann man Jitsi Meet so konfigurieren, dass neue Konferenz-Räume nur mit einem Benutzernamen und Passwort erstellt werden können.
Wer seine Instanz öffentlich betreiben möchte, muss die folgenden Schritt nicht ausführen.
Dazu ist zunächst eine Anpassungen in folgender Datei nötig:
nano /etc/prosody/conf.avail/meet.meinedomain.de.cfg.lua
Hier werden sog. virtuelle Hosts definiert (nicht zu verwechseln mit den virtuellen Hosts von nginx). Der erste virtuelle Host wird nun so eingestellt, dass eine Authentifizierung erforderlich ist:
VirtualHost "meet.meinedomain.de"
authentication = "internal_plain"Am Ende der Datei wird dann ein weiterer virtueller Host hinzugefügt:
VirtualHost "guest.meet.meinedomain.de"
authentication = "anonymous"
c2s_require_encryption = falseAls nächstes wird der neue virtuelle Host der Jitsi Meet Installation bekannt gemacht:
nano /etc/jitsi/meet/meet.meinedomain.de-config.js
Unter der Angabe der eigentlichen Domain wird nun die Domain des zuvor angelegten virtuellen Hosts als „anonyme Domain“ hinterlegt:
hosts: {
// XMPP domain.
domain: 'meet.meinedomain.de',
// When using authentication, domain for guest users.
anonymousdomain: 'guest.meet.meinedomain.de',Nun muss noch eine weitere Datei bearbeitet werden:
nano /etc/jitsi/jicofo/sip-communicator.properties
Hier fügen wir einfach nur eine Zeile ein:
org.jitsi.jicofo.auth.URL=XMPP:meet.meinedomain.de
Nun folgt noch ein wichtiger Punkt: Das Hinzufügen von Benutzername und Passwort zum Erstellen neuer Konferenz-Räume. Dazu einfach folgenden Befehl direkt in die Kommandozeile eingeben:
prosodyctl register JitsiAdmin meet.meinedomain.de 'mEinPAssw0rt'
JitsiAdmin ist in diesem Beispiel der Benutzername, mEinPAssw0rt das dazugehörige Passwort.
Nach den Änderungen an der Konfiguration von Jitsi Meet sind nun noch die entsprechenden Services neu zu starten:
service prosody restart service jicofo restart service jitsi-videobridge2 restart
Verbindungen zu externen Diensten verhindern
Jitsi Meet nutzt einige externe Dienste, wie z.B. Gravatar zum Anzeigen von Benutzer-Icons, wenn die User eine E-Mail-Adresse in den Einstellungen hinterlegt haben und einen Gravatar-Account haben.
Aus Sicht des Datenschutzes ist dies natürlich bedenklich. Wer also auf etwas Komfort verzichten kann, dafür aber Wert auf Datenschutz legt, kann diese Verbindungen zu externen Diensten in Jitsi Meet deaktivieren.
Die Einstellung dazu kann in folgender Datei gesetzt werden:
nano /etc/jitsi/meet/meet.meinedomain.de-config.js
Hier ändern wir nun die entsprechende Variable:
// If third party requests are disabled, no other server will be contacted. // This means avatars will be locally generated and callstats integration // will not function. disableThirdPartyRequests: true,
Zum Übernehmen der Änderungen werden alle Dienste noch einmal neu gestartet:
service prosody restart service jicofo restart service jitsi-videobridge2 restart
Nutzung von Jitsi Meet
Die eigene Instanz kann nun einfach im Browser genutzt werden: https://meet.meinedomain.de.
Hinweis: Es gibt momentan wohl noch kleinere Probleme mit neueren Versionen von Firefox. Daher wird offiziell die Verwendung von Chrome/Chromium empfohlen.
Als erstes sollte eine Blick in die Einstellungen geworfen werden (Zahnrad oben rechts).
Unter Profil kann ein Name und eine E-Mail-Adresse hinterlegt werden. Der Name wird dann in den Konferenzen angezeigt. An Hand der E-Mail-Adresse wird versucht, per Gravatar ein Avatar für den Benutzer anzuzeigen.
Ebenso kann hier die Sprache der Oberfläche angepasst werden. Nach einem Klick auf OK werden die Einstellungen gespeichert.
Ein Konferenzraum kann nun durch Eingabe des Names für das Meeting und einen Klick auf Los gestartet werden. Der Browser fragt dann, ob man Zugriff auf Mikrofon/Kamera erlauben möchte. Dies sollte man bestätigen, ansonsten macht es ja für Video-Konferenzen wenig Sinn.
Der Konferenz-Raum wird dann noch nicht sofort erstellt, sondern es erscheint eine Meldung mit der Frage nach dem Organisator (dieser Schritt belibt aus, wenn ihr nicht die „Secure Domain“ konfiguriert habt, s.o.):
Erst nach einem Klick auf „Ich bin der Organisator“ und der Eingabe von Benutzername und Passwort, welches wir weiter oben konfiguriert haben, wird der Raum eröffnet.
Nun präsentiert sich Jitsi Meet mit einer aufgeräumten Oberfläche. Der folgende Screenshot zeigt dabei alle wichtigen Elemente.
Damit andere Leute nun an der Konferenz teilnehmen können, wird einfach der Link auf die Konferenz benötigt (Schaltfläche unten rechts). Ein konkreter Link könnte dann so aussehen: https://meet.meinedomain.de/MeinMeeting
Hier kann auch gleich ein Passwort für die Konferenz eingetragen werden, damit nicht jeder anonyme Benutzer der Konferenz beitreten kann.
Die Benutzung via Browser stellt vermutlich die einfachste Möglichkeit dar. Allerdings gibt es auch Clients für die unterschiedlichsten Plattformen, siehe Jitsi Download-Seite.
Hinweise für Remote Control: Für die Fernsteuerung von Rechnern (ähnlich Teamviewer), muss ein spezieller Desktop-Client („Jitsi Meet Electron“) auf dem fernzusteuernden Rechner genutzt werden. Dieser kann bei GitHub herunter geladen werden. Der Teilnehmer, der die Bedienung remote übernehmen möchte, kann allerdings auch per Browser an der Konferenz teilnehmen.
Fazit
Die eigene Videokonferenz-Lösung aufzusetzen ist mit Jitsi Meet gar nicht so schwer und innerhalb von kürzester Zeit erledigt. Lediglich die individuellen Anpassungen/Absicherungen gehen ein wenig mehr ins Detail.
Man bekommt dafür eine Lösung für Videokonferenzen, die aus Sicht von Privatsphäre und Datenschutz um einiges besser ist als proprietäre Konferenz-Software eines Unternehmens.
Wie steht es bei euch? Nutzt ihr regelmäßig Audio-/Video-Konferenzen? Habt ihr vielleicht schon eure eigene Jitsi Meet Instanz aufgesetzt? Was sind eure Erfahrungen?
Hinterlasst mir dazu doch einfach einen Kommentar.
Weiterführende Artikel
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
- TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
- Nextcloud Talk mit eigenem TURN-Server (coturn)
Links
- Offizielle Jitsi-Homepage (Englisch)
- Traversal Using Relays around NAT (Wikipedia)
- Session Traversal Utilities for NAT (Wikipedia)
- Liste öffentlicher STUN-Server
- coturn (GitHub)
- Jitsi Download-Seite (Clients für verschiedene Plattformen)
- Client Jitsi Meet Electron Releases (GitHub)
Ähnliche Artikel:
Matrix Synapse auf Ubuntu Server 20.04 LTS mit nginx, PostgreSQL und Let’s Encrypt
Nextcloud Talk mit eigenem Signaling-Server (High Performance Backend)
Matrix: Element auf Ubuntu Server 20.04 LTS mit nginx und Let’s Encrypt
Nextcloud auf Ubuntu Server 22.04 LTS mit nginx, PostgreSQL/MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
Hallo Jan,
klasse, für wieviel Sessions gleichzeitig ist der Server ausgelegt?
Gruss Hans
Hi Hans,
mit Sessions meinst du die Konferenz-Räume, oder? Da sollte es in der Theorie erst einmal keine Beschränkung geben. Kommt halt drauf an, wie viele Nutzer der Server in der Praxis verkraftet.
Aber leider fehlen mir hier noch konkrete Erfahrungswerte.
Gruß,
Jan
Hi Jan,
klasse Artikel – DANKE! Eine kleine Frage:
anonymousdomain: ‚guest.meet.meinedomain.de‘,
oder
anonymousdomain: ‚guests.meet.meinedomain.de‘,
Grüße, Carsten
Hi Carsten,
muss natürlich „guests“ heißen. Der Name an sich ist aber egal, es muss nur deckungsgleich in der Jitsi- und Prosody-Config sein.
Danke für den Hinweis.
Gruß,
Jan
Heyho Jan,
vielen Dank für den Post hier!
Eine kleine Änderung hätte ich noch beizutragen:
Bei der Erstellung möglicher Logindaten muss statt „jitsi-meet.example.com“ natürlich auch noch die passende eigene Domain eingetragen werden.
Nach der Installation konnte ich die Webseite problemlos aufrufen, allerdings immer mit der Meldung das ich die Verbindung verloren hatte. (…und reconncet fehlschlägt)
Oder das nginx plötzlich nichtmehr starten konnte weil Port 443 schon benutzt wird? Laut netstat von jitsi selbst..
In den meisten anderen Tutorials die ich so gefunden hatte wurde auch immer eine Portrange anstatt des einzelnen Ports 10000 geöffnet, hat sich das mit neueren Releases erübrigt?
Vielleicht hast du noch eine Idee woran es liegen könnte..
Viele Grüße und bleib gesund!
Hi Sebastian,
es hatten sich noch zwei kleine Fehler eingeschlichen: Erstmal die Domain für die Login-Daten (danke für den Hinweis!).
Zum anderen der Name des virtuellen Hosts (guests.meet.meinedomain.de). Diese war einmal mit „guest….“ (ohne s) angegeben. Achte darauf, dass es in der Jitsi- und Prosody-Config der jeweils gleiche Name ist.
Meinen Tests zufolge reicht die Freigabe von Port 10000 aus (normalerweise wird in anderen Tutorials die Range 10000-20000 angegeben).
Gruß,
Jan
Unter deiner Config für die SSL Certs (RSA) fehlt an einer Stelle noch ein „E“ -> meet.meinEdomain.de, fiel mir bei Suchen und Ersetzen auf..
Das Verbindungsproblem waren wohl nicht mehr existente STUN Server aus der Liste, die du verlinkt hattest. Habe zu Testzwecken die Google Defaults stehen lassen und hatte anschließend keine Probleme mehr Meetings beizutreten. Werde jetzt noch die eigenen STUN Server hochziehen und meine Config entsprechend abändern.
Auch das Thema mit den Ports scheint sich erübrigt zu haben, bei 4 offenen Meetings kam es zu keinen Problemen.
Danke nochmal für die Anleitung, gerade aktuell sehr hilfreich!
Viele Grüße
Hallo Jan,
kann man den Server auch parallel zu einer Nextcloud aufsetzen? Wenn ja, muss man da auf Besonderheiten achten?
Gruß
Christian
Hi Christian,
ja, sollte kein Problem darstellen, das parallel zu NC zu betreiben.
Jedoch würde ich hier eine zweite (Sub-)Domain für Jitsi empfehlen (und dann eben per CNAME, wenn DynDNS).
Der Flaschenhals könnte hier aber recht schnell die Upload-Bandbreite sein.
Gruß,
Jan
Hallo Christian,
würde mich interessieren ob Du nun die Installation neben der Netxcloud verwirklicht hast. Da ich auch gerne jitsi-meet neben meiner Nextcloud einrichten würde. Also Deine Erfahrungen wären für mich sehr interessant.
Gruß
Thomas
Hey Jan,
klasse! Gerade in Zeiten von Corona ist so ein Tool sehr sinnvoll, da viele Konferenzprogramme doch sehr begrenzt sind.
Eine Frage an dich oder in die Gruppe:
Wenn die Web-Anwendung nach dem Erstellen eines Konferenzraumes meinen Organisatoraccount abfragt, funktioniert die Eingabe des Usernames und des PSW nicht. Darauf hin bin ich in die Datei /etc/jitsi/jicofo/sip-communicator.properties gegangen und habe den Username und das PSW geändert. Leider ohne Erfolg. Gibt es da tiefere Abhängigkeiten?
Die App erfordert auch einen user@domain.net, ist der Benutzername dann doch Username@meinedomain.de?
Wäre super wenn du oder jmd. hier eine Lösung hättest, wie man den Admin neu erstellen kann. Eine Neuinstallation nach „purge“ hat leider nicht das gewünschte Ergbnis gebracht.
Vielen Dank!
Hallo Sascha,
komisch, hier hatte ich bei der Einrichtung noch nie Probleme. Wie hast du den User denn angelegt? Dieser steht nämlich nicht in der Datei „/etc/jitsi/jicofo/sip-communicator.properties“, sondern wird per Kommandozeile einfach über einen Befehl angegeben.
Ich denke mal, dass das hier dein Problem ist.
Habe das im Artikel auch mal etwas deutlicher formuliert.
Gruß,
Jan
Danke für Deine Anpassung. Ich hatte den Komandozeilenbefehl in die Datei sip-communicator.properties kopiert.
Richtig ist natürlich den Befehl
prosodyctl register JitsiAdmin meet.meinedomain.de ‚mEinPAssw0rt‘
via Putty etc. zu übergeben
Hallo Jan,
danke für die Anleitung.
Ich habe das Problem, dass ich von außerhalb meines Netzwerks zwar in die Räume komme, aber keine Ton und Bild bekomme. Ist das zweite Gerät im Netzwerk klappt Ton und Bild Verbindung.
Hast du eine Idee woran es liegen kann?
ich habe aus der Anleitung (https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md#Advanced-configuration) folgendes gemacht:
—
Advanced configuration
If installation is on a machine behind NAT further configuration of jitsi-videobridge is needed in order for it to be accessible. Provided that all required ports are routed (forwarded) to the machine that it runs on. By default these ports are (TCP/443 or TCP/4443 and UDP 10000). The following extra lines need to be added the file /etc/jitsi/videobridge/sip-communicator.properties:
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=
—
Jetzt funktioniert es, aber meine dynamische IP ist ja jetzt fest in der Datei. Das ist blöd.
Grüße Jens
Hi Jens,
OK, erstmal danke für den Hinweis.
Bei einer dynamischen IP ist das natürlich keine Lösung auf Dauer. Hier könnte man aber z.B. probieren, die Werte in der sip-communicator.properties regelmäßig per Cron zu aktualisieren.
Gruß,
Jan
Genau vor dem Problem stehe ich auch. Habe aber bis jetzt kein Lösung. Die Idee mit dem Cronjob hatte ich auch schon, nur habe keinen Ansatz zur Umsetzung.
Hi,
wenn man dies per Cron realisieren möchte, ist die größte Hürde vermutlich, wie man per Bash-Skript die eigene öffentliche IP herausfindet. Dazu gibt es hier ein paar Ansätze.
Gruß,
Jan
Hallo Jan, hallo Bosco,
man muss bei HARVESTER_PUBLIC_ADDRESS gar nicht unbedingt eine IP eintragen. Nach meinem Wissen kann man hier auch eine dyndns-Adresse eintragen. Dann erspart man sich den Cronjob zum aktualisieren der IP.
Ich würde das gerne alles mal bei mir zu Hause in einer VM testen und nur Lokal betreiben.
Was genau muss ich dann anpassen – will es nicht auf eine Domain routen und brauche dann auch wohl nicht unbedingt Let’s encrypt, oder?
Freue mich auf Feedback
Hi,
lokal ist das auch kein Problem. Einfach im Setup als Adresse die lokale LAN-IP eingeben und dann im weiteren Verlauf den Punkt „Generate new self signed certificate…“ wählen. Anschließend ist Jitsi Meet dann per LAN-IP erreichbar.
Gruß,
Jan
leider habe ich lokal schon ein kleines Problem…
mit mehreren Usern funktioniert es nicht dass alle freigebene Dokumente (Bildschirme) sehen können.
für Chrome braucht wohl es eine Erweiterung für das „Sharing“ !
wie bekomme ich diese denn für den „lokalbetrieb“
mit Firefox 74 geht das Sharing ebenfalls nicht !
Gruß
KH
Hi,
hier am besten den Desktop-Client von hier nehmen.
Jitsi Meet ist mit Firefox sehr instabil, daher rate ich von der Verwendung von Firefox (nur in Verbindung mit Jitsi Meet!) ab.
Gruß,
Jan
Hi Jan,
vielen Dank für die Info.
Wie ich den von Dir beschriebenen Desktop-Client „zum Laufen“
bekomme ist mir allerdings noch ziemlich unklar !
Gruß KH
Hallo Jan,
du musst den Desktop Client als Admin starten. Ich bin da auch fast dran verzweifelt…
Gruß
Jan
Hallo Jan,
bist du unter Windows unterwegs? Wenn der Client hier mit Admin-Rechten gestartet werden muss, kann ich dazu ja noch einen Hinweis im Artikel mit aufnehmen.
Leider kann ich es selbst nicht testen, da kein Windows mehr vorhanden.
Gruß,
Jan
Hallo Jan,
die Clients in unserem Unternehmensnetzwerk sind alles Windows 10 PCs und dort läuft der Jitsi Client nur als Admin gestartet.
Gruß
Jan
Hallo,
danke für das verständliche Tutorial!
Eine Frage zum DNS-Resolver: Was muss dort eingetragen werden, wenn es auf einem Server installiert wird? Die IP des nameservers?
ich versuche, jitsi auf einem Strato V-Server zu installieren, bisher klappt das allerdings noch nicht. Devices werden immer als allein im Meeting angezeigt, obwohl beide zu der gleichen URL verbinden. Beim DNS-Resolver habe ich die IP des Strato-Nameservers angegeben, da dieser im DNS-Record für die Domain eingestellt ist.
lg jami
Hi,
ja, das ist der DNS-Resolver – diesen am besten beim Hoster nachfragen.
Aber dennoch: Wenn sich mehrere Geräte auf die gleiche Instanz und in die gleiche Konferenz verbinden, dann müssten diese sich doch sehen können. Ist die Verbindung ansonsten stabil, oder gibt es nach ein paar Sekunden/Minuten Verbindungsabbrüche?
Gruß,
Jan
Hi Jami / Jan,
ich habe das gleiche Problem. (@Jan, ich habe die Serverkonfiguration so hinbekommen, wie im anderen Gästebucheintrag bereits bei dir erfragt. Das funktioniert so)…
Es gibt keine Verbindungsabbrüche oder ähnliches. Die Teilnehmer sehen sich einfach nicht. Den STUN-Server habe ich auch eingetragen.
Die Chatfunktion geht auch nicht.
Fehlermeldung aus der jicofo-log-Datei ist (auszugsweise)
Jicofo 2020-04-09 08:45:52.509 SCHWERWIEGEND: [42] org.jitsi.xmpp.component.Comp onentBase.log() Ping timeout for ID: fsVK5-806
Jicofo 2020-04-09 08:45:52.647 SCHWERWIEGEND: [42] org.jitsi.xmpp.component.Comp onentBase.log() Ping timeout for ID: fsVK5-807
Jicofo 2020-04-09 08:46:02.510 SCHWERWIEGEND: [42] org.jitsi.xmpp.component.Comp onentBase.log() Ping timeout for ID: fsVK5-816
Jicofo 2020-04-09 08:46:02.647 SCHWERWIEGEND: [42] org.jitsi.xmpp.component.Comp onentBase.log() Ping timeout for ID: fsVK5-817
Jicofo 2020-04-09 08:46:07.722 SCHWERWIEGEND: [170] util.UtilActivator.uncaughtE xception().122 An uncaught exception occurred in thread=Thread[pool-110-thread-1 ,5,main] and message was: unable to create new native thread
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor. java:957)
at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolE xecutor.java:1025)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:624)
at java.lang.Thread.run(Thread.java:748)
google-technisch habe ich auch keine Lösung gefunden, sondern lediglich andere, die auch in anderen Anwendung das gleiche Problem haben. Es liegt wohl offensichtlich daran, dass Jitsi eine Reihe von Threads erstellt, diese aber wohl limitiert sind. Der Server hat 8 GB Arbeitsspeicher,
Hi,
ja, der Stacktrace sieht so aus, als ob der Maschine der Speicher ausgeht. Wundert mich nun ein wenig, da 8 GB eigentlich genug sein sollten.
Schau mal parallel zur Videokonferenz auf den Verbrauchten Speicher der Maschine (z.B. mittels htop). Geht das dann massiv nach oben?
Gruß,
Jan
Servus Jan,
nein. Der Speicher pendelt sich bei kanpp unter 400 MB ein.
Problem ist, dass ich auch nur mich sehe. Ich habe hier auch das gleiche Problem, wie Jami, dass ich andere Teilnehmer nicht sehe, die aber eigentlich im gleichen Raum sein müssten. Ich vermute, dass das eine Problem mit dem anderen zu tun hat. Wegen den Fehlern sehe ich möglicherweise nicht meine Kollegen. Um die Firewall auch auszuschließen, habe ich sie auch auch schon mittels ufw allow out 10000:20000 da auch frei gemacht. Wobei die ausgehenden Verbindungen ja sowie gehen müssten.
An meinem Clients, die sich mittels Browser auf den SErver verbinden liegts denke ich auch nicht. Ich habe derzeit leider noch keine Webcam, aber meinen Bildschirm kann ich frei geben und das Micro funktioniert offensichtlich auch. Zumindest in meiner Instanz. In der von Kollegen, obwohl sie im gleichen Raum sein sollten, sieht und hört man nichts.
Mir ist gerade aufgefallen, dass hier die Tasks 60 (limit 60) haben
jicofo.service – LSB: Jitsi conference Focus
Loaded: loaded (/etc/init.d/jicofo; generated)
Active: failed (Result: exit-code) since Thu 2020-04-09 21:22:47 CEST; 15s ago
Docs: man:systemd-sysv-generator(8)
Process: 32105 ExecStop=/etc/init.d/jicofo stop (code=exited, status=2)
Process: 6524 ExecStart=/etc/init.d/jicofo start (code=exited, status=2)
Tasks: 60 (limit: 60)
CGroup: /system.slice/jicofo.service
└─301 java -Xmx3072m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi
jicofo kann deshalb womöglich nicht starten.
Kann man das Limit ändern?
Hi,
sind die betroffenen Ports auch bei den Clients offen? Wenn nicht, würde ich das mal ausprobieren.
Aber das scheint wohl ein allgemeines Problem zu sein mit „Out of memory“, sie hier. Ich denke, da muss seitens Jitsi/Jicofo geändert werden.
Gruß,
Jan
Hi ich wüsste jetzt nicht, wie ich lokal die Port öffnen sollte.
In der Firewall der Firtzbox oder an meinem PC? Beide?
Die Frage ist aber hier, warum. Die Verbindung wird von meinem REchner aus iniziiert. Die Firewall blockt grundsätzlich nur anfragen von außen.
Das ist ja der Grund, warum jeder ne Firewall installiert bekommt und trotzdem noch surfen kann.
Hi Florian,
ja, auf der FB und den Clients selbst.
Aber das wird bei deinem Problem wohl leider nicht wirklich helfen, da du ja schon einen Programm-Fehler in den Logs feststellen konntest.
Gruß,
Jan
Servus Jan.
Hab es mit einem alten Bekannten und Linux-Guru hinbekommen. Probem war bei mir, dass ich zunächst die DNS-Konfiguration nicht ganz richtig gesetzt habe.
Habe nur cloud.meinedomain.de umgebogen und nicht *.cloud. Das war Fehler Nr. 1. Deshalb konnte auth.cloud.meinedomain.de nicht gefunden werden und die XMPP-Auth Geschichte ist ins Leere gelaufen.
Fehler Nr. 2 war, dass aus irgendwelchen Gründen die Threats, die Java erstellt, auf 60 limitiert waren. Es müssten – auch gem. Standardkonfiguration von Jitsi – 65000 sein. Warum das so war weiß ich nicht. Letztlich haben diese zwei Fehler dazu geführt, dass das Teil nicht richtig starten konnte.
Grüße
Flo
Hi Flo,
sprichst du hier von Domains? Als Domain muss nur meet.meinedomain.de existieren. Die anderen Sachen (z.B. guest.meinedomain.de) sind keine Domains, sondern sind interne Konstrukte von Jitsi Meet, mit denen die Dienste untereinander kommunizieren.
Die Einschränkung auf Threads/Dateien lässt sich übrigens aufheben, siehe hier.
Gruß,
Jan
Hallo Jami,
meiner Erfahrung nach mit Jitsi Meet kommt es zu diesem Verhalten, dass jeder nur sich sieht, wenn die Firewall sowohl den eingehenden Traffic auf 10000 und den ausgehenden Traffic auf 10000 blockiert.
Gruß
Christoph
Moin Jan,
ich denke, der Pfad müsste noch angepasst werden, oder?
[…] location /external_api.js {
alias /srv/jitsi-meet/libs/external_api.min.js;
}
[…]
=> Korrekturvorschlag:
alias /usr/share/jitsi-meet/libs/external_api.min.js;
Viele Grüße,
Carsten
Hi,
ich habe versucht Secure Domain einzurichten. Beim Anlegen bekomme ich die Fehlermeldung ‚prosodyctl register JitsiAdmin turn.meet.wydler.eu Test1234!‘ Es handelt sich um einen Ubuntu 18.04.4 LTS auf dem sonst nichts installiert ist. Jitsi habe ich über das Repo geholt.
Kann es an der neuen Version von heute liegen?
Liebe Grüße
Hi Dani,
auch wenn sich seit dem letzten Update eine ganze Menge geändert hat, ist die Einrichtung der User immer noch gleich geblieben.
Du versuchst hier, einen User für „turn.meet.wydler.eu“ anzulegen. Sicher dass die Domain korrekt ist, müsste das nicht eher „meet.wydler.eu“ heißen?
Gruß,
Jan
Hallo,
vielen Dank für den Klasse Artikel, der mir sehr weitergeholfen hat.
Wir nutzen das System für Home-Schooling.
Ich habe nur eine Frage: Kann man die Funktionalität deaktivieren, dass Teilnehmer ein Meeting zu YouTube streamen können?
Ich vermute, dass dies eine globale Einstellung ist, finde sie aber nicht.
Vielen Dank,
Caroline
Hallo Caroline,
das Live-Sreaming ist in der Standard-Installation gar nicht aktiviert. Du könntest aber in der Datei /usr/share/jitsi-meet/interface_config.js in der Option TOOLBAR_BUTTONS die Option fürs Streaming rausnehmen. Dann wird die Option in der Toolbar gar nicht mehr angezeigt.
Gruß,
Jan
Hi,
erst mal: Super Anleitung, ich bin sogar ziemlich weit gekommen :)
Ich hab im letzten Schritt ein Problem und zwar bei:
prosodyctl register JitsiAdmin meet.meinedomain.de ‚mEinPAssw0rt‘
Das sieht bei mir ca so aus:
prosodyctl register MeinNick meine-domainde ‚undmeinPasswort‘
Es kommt aber die Fehlermeldung:
The given hostname does not exist in the config
Heißt das ich muss „MeinNick“ noch in die config hinzufügen?
beste Grüße
Michael
Hi Michael,
nein, es geht hier nur um den fett markierten Teil: prosodyctl register MeinNick meine-domainde ‚undmeinPasswort‘
Diese Domain wird beim Jitsi Meet Setup abgefragt und in zahlreichen Dateien/Configs hinterlegt. Diese Domain muss stimmen, damit prosodyctl hier User anlegen kann.
Gruß,
Jan
Servus Jan,
vielen Dank für deine Tutorials. Habe gestern das NextCloud Tutorial durchgemacht und es läuft alles :)
Wollte nun heute Jtisi parallel dazu installieren aber bekomme es nicht wirklich zum laufen. Faszinierender Weise wird mir im Browser jedoch dies angezeigt:
404 Not Found
You can create new conversation here
Also irgendwie scheint doch etwas zu funktionieren.
Meine Hardware-Voraussetzungen sind etwas kompliziert. Letztlich habe ich eine Domain beim Provider A und meinem VPS beim Provider B und ich habe es hinbekommen, dass ich eine Subdomain vom Provider A auf die IP von meinem VPS umgebogen bekomme. Deshalb läuft unter https://cloud.meinedomain.de/nextcloud auch die Nextcloud. Unter https://cloud.meinedomain.de/jitsi möchte ich nun Jitsi zum Laufen bekommen.
Installation von Jitsi habe ich mit der Domain cloud.meinedomain.de durchlaufen lassen. Die Letsencrypt-Zertifikate hatte ich noch von von der Nextcloud-Installation. Soweit stimmt das alles mit deiner Konfiguration überein. Jetzt wirds tricky:
Wollte natürlich auch, nach deinem Vorbild, die NGINX VHost-Dateien entsprechen umbiegen.
Habe ich jetzt natürlich eine cloud.meinedomain.de_nextcloud.conf, eine cloud.meinedomain.de.conf und eine cloud.meinedomain_jitsi.conf.
Mir ist aufgefallen, dass die SSL-Einträge in deiner Jitis-Conf fast identisch sind mit der aus dem nextcloud-Tutorial. Diese habe ich deshalb in der cloud.meinedomain.de.conf per include mit eingefügt.
Die Jitsi-Conf sieht bei mir jetzt so aus:
root@h2879070:/etc/nginx/conf.d# cat cloud.meinedomain.de_jitsi.conf
server_names_hash_bucket_size 64;
server {
listen 127.0.0.1:83;
server_name 127.0.0.1;
# Path to the root of your installation
root /usr/share/jitsi-meet;
ssi on;
index index.html index.htm;
error_page 404 /static/404.html;
location = /config.js {
alias /etc/jitsi/meet/cloud.meinedomain.de-config.js;
}
location = /external_api.js {
alias /usr/share/jitsi-meet/libs/external_api.min.js;
}
#ensure all static content can always be found first
# location ~ ^/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
location ~ ^\/jitsi\/(libs|css|static|images|fonts|lang|sounds|connection_optimization|.well-known)/(.*)$
{
add_header ‚Access-Control-Allow-Origin‘ ‚*‘;
alias /usr/share/jitsi-meet/$1/$2;
}
# BOSH
location = /http-bind {
proxy_pass http://localhost:5280/http-bind;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
}
# external_api.js must be accessible from the root of the
# installation for the electron version of Jitsi Meet to work
# https://github.com/jitsi/jitsi-meet-electron
location /external_api.js {
alias /usr/share/jitsi-meet/libs/external_api.min.js;
}
location ~ ^\/jitsi\/([^/?&:'“]+)$ {
try_files $uri @root_path;
}
location @root_path {
rewrite ^/(.*)$ / break;
}
}
Parallel zu der NGINX-NextCloud-Config habe ich die „location“ in der ^~ steht um \/jitsi/\ erweitert.
Die cloud.meinedomain.de.conf -Datei sieht so aus, wie du sie in deinem nextcloud-Tutorial beschrieben hast. Hier habe ich nur den Nextcloud-Eintrag kopiert und auf Jitsi abgeändert.
location ^~ /jitsi/{
# Set max. size of a request (important for uploads to Nextcloud)
client_max_body_size 10G;
# Besides the timeout values have to be raised in nginx‘ Jitis config, these values have to be raised for the proxy as well
proxy_connect_timeout 3600;
proxy_send_timeout 3600;
proxy_read_timeout 3600;
send_timeout 3600;
proxy_buffering off;
proxy_request_buffering off;
proxy_max_temp_file_size 10240m;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://127.0.0.1:83;
proxy_redirect off;
}
Ich weiß nicht, wo ich ansetzen muss, um das zum laufen zu bekommen. Ich hoffe, du kannst mir helfen.
Grüße Flo
Hi Flo,
ich kann dir gar nicht sagen, ob du Jitsi Meet in ein Unterverzeichnis „installieren“ kannst. Du hattest hier ja schon den richtigen Ansatz, weil ein Teil ja funktioniert. Aber es scheitert wohl noch an was anderem.
Mach es doch einfacher: Besorg dir eine zweite (Sub-)Domain für Jitsi. Dann kannst du 1:1 wie im Artikel beschrieben vorgehen. Und die Konfiguration seitens des Webservers wird sehr viel einfacher.
Wäre das eine Option?
Gruß,
Jan
Hi Jan,
Danke erst mal für die Antwort.
Ich weiß noch nicht, ob das eine Option ist. Problem ist, dass ja, dass die Nextcloud schon normal läuft.
Ich habe ja schon meine Subdomain direkt auf die IP des Servers gelinkt.
Dies bedeutet, dass ich mit cloud.meinedomain.de schon jitsi aufgerufen werden würde. Das wäre grundsätzlich nicht das Problem.
Ändert sich dann die ursprüngliche VHost Konfiguration? cloud.meinedomain.de würde jitsi aufrufen und mit cloud.meinedomain.de/nextcloud käme ich direkt in meine nextcloud-Instanz.
Dann bräuchte es nur einen Verweis in der cloud.meinedomain.de.conf auf die nextcloud-Instanz und der Loopback-Adresse mit Port 81. die cloud.meinedomain.de_nextcloud.conf bleibt so, wie sie ist und hört auf 127.0.0.1:81.
in der cloud.meinedomain.de.conf stehen die Konfigurationen, wie sie in deinem Beitrag genannt sind.
Ist das so richtig?
Den Serverbereich in der cloud.meinedomain.de.conf-Datei, der sich um Port 80 kümmert kann auch weiterhin auskommentiert bleiben oder? Jitsi soll ja schließlich nur auf 443 laufen.
Hi,
ich würde davon abraten, die Konzepte „1 vHost pro Domain“ und „Gateway-Host“ zu mischen. Das wird dann nur noch komplizierter.
Daher die Empfehlung, für Jitsi Meet eine eigene Domain her zu nehmen. Das würde ich erst einmal umsetzen (Sub-Domain kostet ja nix), dann kann man zumindest schon mal sicher gehen, ob Jitsi Meet überhaupt funktioniert.
Gruß,
Jan
Hallo Jan,
hast du beide Server (meet.meinedomain.de und turn.meinedomain.de) bei netcup laufen.
Nachdem man hierfür zwei Server benötigt kann das gut teuer werden.
RS 500 SSD G8 x 2 = 12 EUR im Monat.
Die Domains hast du dann wahrscheinlich bei All-Inkl.
Gruß Hans
Hi Hans,
Jitsi Meet und coturn können auf dem gleichen Server laufen, das ist kein Problem.
Gruß,
Jan
Hallo Jan,
ich bin auch sehr beeindruckt von all deinen Artikeln.
Bei mir funktioniert Jitsi Meet auch eigentlich gut.
ABER leider kommt es doch häufiger vor, dass das Videobild von manchen Teilnehmner einfriert. Ein Reload der Website behebt das Problem und der Teilnehmer sieht wieder alle Streams.
Dieses Verhalten ist jedoch in einem produktiven Betrieb nicht gerade „günstig“. Browser hab ich die aktuellen Versionen von Chrome und Firefox benutzt.
Hast du von solchen Problemem schon gehört bzw. gibt es dafür eine Lösung
lg Roman
Hi Roman,
bisher hatte ich damit keine Probleme. Gibt die Browser-Console beim Einfrieren irgendwelche Warnungen/Fehler aus?
Passiert das gleiche auch, wenn du den Desktop-Client oder die App verwendest?
Gruß,
Jan
Performance-Bericht meinerseits:
Ich habe Jitsi-Meet auf die virtuelle Systeme (Hyper-V2) Ubuntu Server 16.04, 18.04 und Debian 10.03(minimal Server Installation) getestet.
Hardware: 2 Intel Xeon E5-2650v4 2,2 GHz (also jede Menge Power)
Beste Performance:
Ubuntu Server 16.04 mit 4 GB RAM und 8 CPUs schafft 30 Participants auf 720p und mit frameRate auf openend. Mehr als 8 CPUs entsteht mehr loadaverage! Java Code ist hier nicht wirklich auf mehr als 8 CPUs utilized. Vielleicht ist auch die JVM einfach zu schlecht für Real-Time-Anwendungen. War schon immer so!
Hinweise:
Achtung bei 25 Participants ist schon mehr als 45 Mbps Outbounds(Netzwerkbandbreite) nötig!!! Wir haben aber zum Glück 1Gbit in/outbounds. Und ich denke mal bis 50 Participants würde unser Jitsi-Instanz schaffen. Die Skalierung hilft nur bei vielen Konferenzen. Also Loadbalancing für einen Konferenzraum gibt es nicht. Es sei denn, jemand von euch ist ein System-Engineer und kreirt sich eine Möglichkeit aus Clustering- und Loadbalancing-Konzepte.
Keine Netzwerkbeschleunigung über Jumbofames oder über sysctl! Führt alles zur gravierenden Verschlechterung von Performance.
Schalte das Loggen von JVA, Jicofo, Prosody und nginx aus oder nur auf ERROR. Dann gewinnt ihr mehr CPUZeit für Real-Time-Process.
Keine IP-Blockierungen in ufw!!! Wenn ihr feste Termine für eure Konferenzen habt, dann macht dafür gesteuerte Skripten um das Loggen in nginx, Einstellung von ufw und weitere Sicherheitseinstellungen in Togglemodus zu versetzen. D. h. wird eine Konferenz stattfinden, dann per Cron das Loggen ausschalten bzw. ufw auf keine IP-Filterung umschalten. Nach der Konferenz wieder das System per Cron sicherer machen!!!
Und Ubuntu Server 16.04 auf dem Niveu von Debian Minimal-Server bringen! Also unnötige Dienste rausschmeißen!
Die Docker-Lösung habe ich noch nicht probiert. Aber hier sehe keine Performancevorteile wegen dem angepassten Kernel und LXD-artige Containerconzept von Docker. Aber ich werde das demnächst testen und vielleicht hier etwas darüber berichten.
Hallo Marius,
das sind sehr interessante Erkenntnisse. Vielen Dank dafür!
Eine Frage hätte ich nur zu ufw und IP-Filterung. Meist du damit Regeln wie z.B.
ufw deny from 192.168.1.5 to any?Ist ein
ufw default denyund die generelle Freigabe von Ports (nicht beschränkt auf gewisse IP-Adressen) auch problematisch?Gruß,
Jan
Hi Jan,
für ein Realt-Time-Anwendung wie VoIP/Videokonferenz über Internet ist ein internes softwareseitiges Firewalling immer ein Zusatzlast bzw. Ausbremsung der Datenkommunikation. Aber ufw ohne IP-Blockierungen nimmt keine dynamische zusätzliche Resourcen. Damit kann man also leben meiner Meinung nach.
Besser aber, wenn man so oder so ein gutes Stück Hardware für den Router hat, dann reicht das völlig aus. Also, kein Software-Firewall dafür eine „guter“ Router mit guter Hardware(im Niveau von Industriestandard) und vielleicht auch das QoS für VoIP vernünftig einstellen. Und durch NAT können die restlichen Dienstblockierungen verwaltet werden. Und ufw im eigentlichen Jitsi-System kann abgeschaltet werden. Was gibt denn da schon zu holen? Snaptshot vom produktiven Zustand machen und jeden Tag um 0 Uhr zurücksetzen, falls man virtuellen Manager zum Einsatz hat.
BTW. Ein GBit-Netzwerkkarte mit 1Gbit Bandbreite hört sich eigentlich ganz gut an. Aber das Problem ist, sind die unmengen kleinen UDP-Pakete von z. B. VoIP von vielen Teilnehmern. Auch, wenn die gesamte Nutzbandbreite (up/down) weit unter 100Mbit liegt, können Overheads im Netzwerk entstehen. Und das ist überhaupt nicht gut für Real-Time-Anwendungen.
Deshalb versuchen wir, wenn man die Firepower hat, also CPU ohne Ende, dann würden wir nur die Netzwerkskalierung machen. Ich glaub Prosody(korregiere mich, falls ich falsch liege) spielt hier als Loadbalancer. Für einen Konferenzraum mit mehr als 50 Participants würde ich sagen 2 PCIx16-Netzwerkkarten von Intel. Wir müssen aber hierfür noch tief in die Konfiguration und vielleicht auch in den Code reinschauen, ob das überhaupt möglich ist. Ich hoffe, wir kommen überhaupt dazu! Dann werde ich hier sicherlich was davon berichten! Frohe Ostern!
Vielen Dank erst mal für die tolle Anleitung.
Jitsi läuft grundsätzlich im geschützten Modus mit prosody.
Leider funktioniert der guest-Mode nicht
Was ich nicht verstehe: Im Prosody Logfile wird guest.meet.meinedomain ausgeworfen. Ich finde jedoch keine Konfigurationsdatei, in der das drin steckt.
Hat jemand einen Tipp, wo ich da noch suchen könnte?
cat /var/log/prosody/prosody.err
Apr 11 18:12:41 guest.meet.meinedomain.de:tls error Error creating context for c2s: No key present in SSL/TLS configuration for guest.meet.meinedomain.de
Apr 11 18:12:41 guest.meet.meinedomain.de:tls error Error creating contexts for s2sin: No key present in SSL/TLS configuration for guest.meet.meinedomain.de
Apr 11 18:17:17 portmanager error Error binding encrypted port for https: No key present in SSL/TLS configuration for https port 5281
Apr 11 18:17:17 portmanager
Hallo Klaus,
da scheint irgendwas mit den Zertifikaten nicht zu klappen. Wie es aussieht, sind das aber nicht die „echten“ TLS-Zertifikate (für die Jitsi Domain selbst), sondern „interne“, als selbst signierte Zertifikate, mit denen die Dienste untereinander kommunizieren.
Ich würde nun mal darauf tippen, dass beim Setup von Jitsi irgendwas schief gelaufen ist. Leider gehen die Fehlermeldungen hier sehr schnell im Konsolen-Output unter. Von daher der Tipp: Alles nochmal deinstallieren und von vorn beginnen. Diesmal beim Setup explizit nach Fehlermeldungen Ausschau halten.
Gruß,
Jan
Vielen Dank für den Tipp. Zertifikatsproblem gelöst.
Die Port Meldung ist wohl kein Fehler
Nach mehrfachen Installationen mit Ubuntu / Debian auf einem Hetzner server habe ich immer noch das Problem, dass meet.domain.de mit Moderation funktioniert, jedoch nicht guest.meet.domain.de
In den logfiles gibt es jedoch keinen Fehler.
Symtomatik: Chrome Browser kann eine Session öffnen, Kamerasymbol jedoch deaktiviert und lässt sich auch nicht aktivieren.
iOS: App sagt, die Konferenz gibt’s noch nicht und will Moderator-Daten zum start einer neuen Session.
Hat noch jemand einen tipp, wo ich suchen könnte. Zum Test ist die Firewall mal komplett deaktiviert, d.h. an der kann es auch nicht liegen.
Hi Klaus,
ah, ich glaube, dass es da noch ein Verständnisproblem gibt.
Die einzige Domain, mit der du dich mit Jitsi Meet verbindest (ob nun Admin, oder „Gast“), ist meet.meinedomain.de.
Nur der Admin kann dann durch Eingabe von Username und Passwort einen Raum eröffnen.
guest.meinedomain.de ist keine Domain, sondern nur ein Jitsi-internes „Verwaltungskonstrukt“. Hier darfst du keine Domain aufsetzen, mit der du Jitsi Meet ansurfen kannst.
Also Admins oder „Gäste“ gehen immer über die Domain meet.meinedomsin.de.
Gruß,
Jan
>>ah, ich glaube, dass es da noch ein Verständnisproblem gibt.
Genau das war der Fall.
Vielen Dank!.
Hallo,
ich probiere mich gerade ebenfalls an Jitsi aus und habe mich für einen ersten Versuch an dieser Anleitung entlang gehangelt. Quasi zum grundsätzlichen Testen, bevor es was produktives werden soll. Verwendet wird ein Pine Rock64, während Jitsi in einem Docker-Container betrieben wird.
Jitsi ist soweit auch erreichbar und ich kann auch einen Konferenzraum öffnen. Bei der Authentifikation bekomme ich unter Verwendung der korrekten Userdaten (prosodyctl register ich meine.dyndns.adresse meinPasswort) den Fehler „connection.GET_SESSION_ID_ERROR“.
Sicher was banales – kann mich jmd. auf die richtige Fährte locken?
Ciao,
Mészi
Hi Mészi,
zu einer Installation via Docker kann ich leider nichts genaues sagen. Ich würde hier zunächst mal die Logs des Containers checken.
Diesbzgl. bitte auch das hier beachten.
Wenn du es zum Laufen bekommst, würde mich mal interessieren, wie es von der Performance her auf einem solchen Kleinst-Computer aussieht. Hat der Rock64 genug „Dampf“ für Jitsi Meet?
Gruß,
Jan
Hallo Meszi,
selbst für ein p2p Session würde ich dieses Experiment gleich lassen. Damit wirst du kein Konferenzraum mit mehr als 3 Participants stabil halten können und nicht bei 720p. Docker oder nicht! Bei 2 Teilnehmer kannst du meet.jit.si auch benutzen. Denn dort ist Standard mäßig p2p und e2e aktiviert. Also keine Angst wegen Daten. Erst ab 3 Personen dürfte der Server von meet.jit.si als Empfänger werden.
Hallo! Vielen Dank. Kann ich irgendwo sehen welche Räume aktuell auf meinem Server offen sind? Gibt es auch soetwas wie eine Statistik, Anzahl der Räume, Tln. etc (keine Metadaten versteht sich) ;-)
Hi Martin,
ja, Jitsi bietet hier eine REST-Schnittstelle zum Abfragen solcher Daten, siehe hier.
Gruß,
Jan
Hallo Jan,
vielen Dank für die Anleitungen, die mir als Anfänger erlauben, einen Nextcloud-Server zu haben und dabei einigermaßen zu verstehen, welche Konfiguration ich da verwende!
Ich habe zu der Jitsi-Anleitung zwei Fragen:
1)
Sehe ich das richtig, dass dieses Problem hier
https://github.com/jitsi/docker-jitsi-meet/blob/master/CHANGELOG.md#stable-4384-1
nur die Docker-Version betrifft und deswegen beim Vorgehen nach Deiner Anleitung unerheblich ist?
2)
Ich habe mit Deiner Anleitung JitsiMeet soweit hinbekommen, dass die Begrüßungsseite erscheint. Wenn ich mich dann eine Konferenz starte, sehe ich mich manchmal ganz kurz, dann wieder nicht und es wird angezeigt, dass es ein Problem gibt und in ca 25 Sek wieder ein Verbindungsversuch unternommen wird, der dann auch scheitert.
In der Datei jicofo.log bekomme ich :
Jicofo 2020-04-15 21:10:48.909 WARNUNG: [67] org.jitsi.jicofo.xmpp.FocusComponent.processIQ() (serving component ‚Jitsi Meet Focus‘) Unexpected exception while processing IQ stanza: <iq$
net.java.sip.communicator.service.protocol.OperationFailedException: Failed to join the room
at [Diverse]
Caused by: org.jivesoftware.smack.XMPPException$XMPPErrorException: XMPP error reply received from conference.v2XXX.XXXsrv.de: XMPPError: remote-server-not-found – cancel
Dabei ist „v2XXX.XXXsrv.de“ der von mir verwendete Domainname.
Gibt es eine Idee, wo ich nach dem Fehler suchen kann?
Liegt es ggf daran, dass „v2XXX.XXXsrv.de“ keine von Subdomain einer von mir gebuchten Domain ist, sondern der Name, unter der dieser netcup-vserver erreichbar ist, ohne dass ich dazu eine Domain gebucht hätte?
Dankbare Grüße, Jan
Hi Jan,
zu 1: Ja, da ist meines Wissens nur die Docker-Variante betroffen.
2: Du hast also nur den Server, aber noch keine Domain dazu? Ich denke, dass du hier eine Domain benötigst. Der Maschinen-Name (ich denke mal, dass es das ist) wird hier nicht ausreichen. Wenn du dir die Domain besorgt hast, dann installiere Jitsi Meet am besten nochmal komplett neu, da der Domain-Name in zahlreichen Configs zu finden ist. Das alles zu ändern ist denke ich aufwändiger als eine Neuinstallation.
Gruß,
Jan
zu 2:
das ist exakt das problem das ich auch hatte.
man braucht zuerst unbedingt eine echte domain und dann am besten alles völlig neu installieren, sonst bist tage beschäftigt..
Hallo Jan,
hab mit interesse deinen Artikel gelesen. Ich habe da kurz eine Frage zu.
Was muss ich beachten wenn ich eine vServer – Debian 9 – Plesk 18 am laufen habe und nginx sowie letsencrypt über Plesk verwalte?
Danke und Bleibt Gesund
Jan
Hallo Jan,
super Anleitung. Ich habe diesbezüglich ein Frage.
Was muss ich beachten, wenn ich die Subdomain, Let’s Encrypt und nginx auf eine vServer mit Debian 9 und Plesk 18 über Plesk veralte?
Gruß auch ein Jan
Hi Jan,
mit Plesk habe ich leider keine Erfahrung. Aber ich denke, dass die Zertifikate dann allein über Plesk verwaltet werden. D.h. du kannst dir das Ausstellen der Zertifikate über acme.sh sparen.
Gruß,
Jan
Jan, 2018 hat mir Nextcloud-Anleitung geholfen und jetzt die Jitsi-Anleitung. Vielen Dank für die Mühe! – Die Anleitungen sind wirklich gut!
Hallo,
ich habe mich an die Anleitung gehalten und soweit alles eingerichtet, https funktioniert, die jitsi Seite ist erreichbar, allerdings kann ich keinen Raum erstellen, es steht die ganze Zeit nur Session-ID wird eingerichtet da.
Wenn ich erlaube das Anonym Räume erstellt werden können, kann niemand beitreten, die Meldung kommt allerdings nicht.
Wo könnte der Fehler liegen?
Hi Sebastian,
hier am besten mal in die Logs schauen: /var/logs/jitsi
Sonst kann man den Fehler wohl kaum eingrenzen.
Gruß,
Jan
Hi Jan,
Anbei mal Auszüge aus den Logs.
Eventuell hast du ja einen Tip.
jicofo.log:
Jicofo 2020-04-26 19:35:21.548 SCHWERWIEGEND: [33] org.jitsi.impl.protocol.xmpp.OpSetSimpleCapsImpl.getItems().61 Error while discovering the services of sub.domain.tld , error msg: No response received within reply timeout. Timeout was 15000ms (~15s). Waited for response using: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=4RYO9-3188)), : fromFilter (OrFilter: (FromMatchesFilter (full): sub.domain.tld)).
Jicofo 2020-04-26 19:35:21.548 SCHWERWIEGEND: [33] org.jitsi.jicofo.ComponentsDiscovery.log() Failed to discover services on sub.domain.tld
Jicofo 2020-04-26 19:35:22.221 SCHWERWIEGEND: [38] org.jitsi.jicofo.health.Health.log() No MUC service found on XMPP domain or Jicofo has not finished initial components discovery yet
Jicofo 2020-04-26 19:35:22.221 SCHWERWIEGEND: [38] org.jitsi.jicofo.health.Health.log() Health check failed in PT0S:
java.lang.RuntimeException: No MUC component
at org.jitsi.jicofo.health.Health.check(Health.java:114)
at org.jitsi.jicofo.health.Health.performCheck(Health.java:88)
at org.jitsi.health.AbstractHealthCheckService.run(AbstractHealthCheckService.kt:144)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)
Jicofo 2020-04-26 19:35:22.248 SCHWERWIEGEND: [41] org.jitsi.xmpp.component.ComponentBase.log() Ping timeout for ID: 4RYO9-3191
Jicofo 2020-04-26 19:35:22.289 SCHWERWIEGEND: [41] org.jitsi.xmpp.component.ComponentBase.log() Ping timeout for ID: 4RYO9-3192
jvb.log:
2020-04-26 19:38:08.108 INFORMATION: [17] VideobridgeExpireThread.expire#144: Running expire()
2020-04-26 19:38:08.379 INFORMATION: [19] Videobridge.createConference#319: create_conf, id=614bc9840698d3a9 gid=null logging=false
2020-04-26 19:38:08.382 INFORMATION: [19] AbstractHealthCheckService.run#171: Performed a successful health check in PT0.003S. Sticky failure: false
Hi Sebastian,
leider sagt mir das alles auch nichts, aber es sieht so aus, als ob er Probleme beim Auflösen der Domains hat.
Bitte prüfe noch einmal Schritt für Schritt alle Punkte des Tutorials, vielleicht wurde hier eine Kleinigkeit übersehen. Bitte auch mal checken, ob alle Services korrekt laufen.
Gruß,
Jan
Hallo Jan und alle hier!
vielen Dank für das super Tutorial und die knstruktiven Beiträge!
Ich hab die Installation allerdings aufgrund einer Anleitung in Youtube zwar schon generell hinbekommen aber es läuft nicht wie ich es mir vorstelle. Und Infos zu meinem speziellen Setup konnte ich noch nicht finden.
Ich würde gerne folgendes Szenario realisieren wenn das denn geht:
Es besteht ein kleines Heimnetz an einem VDSL Anschluss (dynamische IP Adresse z.B. xyz.goip.de oder evt. auch feste IP Nummer 85.x.y.z).
Fritzbox als Router, dahinter diverse PCs, NAS, usw.
Nun hab ich auf einem ungenutzten PC Ubuntu frisch installiert (lokale IP 192.168.1.13 o.ä.) und möchte diesen PC intern aber auch aus den Netz als Jitsi Server nutzen.
Im Prinzip finktioniert die Jitsi Installation, auch die nginx Verzeichnisse und Einträge werden bei der Installation erstellt.
Wie auch immer, aber bei der Konfiguration scheitere ich.
1. Ich habe ja keine „echte“ Domain, also was würde ich als „hostname“ nehmen bzw. in die hosts Datei eintragen?
2. Bei der Jitsi Installation werde ich nach der Domain gefragt aber sowas habe ich ja mit meinem setup nicht. Nehme ich nun die Dyndns xyz.goip.de oder die Heimnetz IP Adresse des Rechners?
3. Kann da ein (selfsigned) Zertifikat ausgestellt werden?
4. Ich kann in der Fritzbox ports weiterleiten. UDP10000 wäre kein Problem aber port 80 ist schon für einen anderen Webserver benutzt, 443 auch.
Wenn ich hier exoten Ports nehme klappt das dann auch wenn man von außen (WAN) auf den JitsiPC zugreifen will für ein meeting.
4a. Welche firewall Regeln muss ich dann auf dem Jitsi Server anwenden?
5. Weitere Konfigurationsschritte würde ich evt. später machen, also STUN ändern, authentification usw.
Und dann evt. eine etwas individuelle GUI für die Konfernzen.
Das hier basiert auch auf Jitsi: https://klassenzimmer.meetzi.de
Ich finde das Jitsi System super und ich möchte lieber solche Projekte unterstützen als Teams, Zoom o.ä. obwohl ich schon gelesen habe, dass Jitsi aufgrund der „internen Technik“ nicht für viele gleichzitige Benutzer funktioniert. Auch etwas ärgerlich, dass Firefox als einer der „großen“ Browser nicht voll unterstützt wird. Das liegt wohl zum Teil auch an Mozilla aber da sollte es im Sinne der User schon eine gemeinsame Entwicklung geben. Wie auch immer, ich denke das wird schon…
Vielen Dank für sachdienliche Hinweise :-)
#stay_healthy
Hi,
zunächst einmal der Hinweis, dass Jitsi doch schon einige Anforderungen an die Bandbreite hat. Wenn du also nicht min. 100 MBit/s Upload am Internet-Anschluss hast, dann würde ich die „Home-hosted“ Variante nicht unbedingt empfehlen.
Zu deinen Fragen:
1. Die DynDNS-Domain.
2. Ebenfalls DynDNS-Domain.
3. Ja, würde ich aber nicht empfehlen. Am besten immer ein Let’s Encrypt Zertifikat nehmen/nachrüsten.
4. Entweder exotische Ports (dann klappt das aber auch mit Let’s Encrypt nicht mehr). Besser wäre wohl ein Server, der über Port 80 und 443 erreichbar ist und die Anfragen entsprechend im Netzwerk weiterleitet (proxy_pass).
4a: Wie im Artikel beschrieben.
Gruß,
Jan
Hallo Jan,
danke für deine Ausführungen, ich werd das mal probieren.
Ich hab hier 110 MBit down und 32 Upload. Wenn ansonsten nicht viel läuft müssten damit 5-8 Teilnehmer (video auf standard quality) machbar sein, oder? Ich sehe bei Jitsi so im Durchscnitt bei 2-3 MBit upstream oder kann man das nicht einfach hochrechnen?
Detailfrage: Wenn ich meinen Bildschirm/Fenster teile dann sehen die Teilnehmer meinen Mauszeiger nicht. Das macht eine Präsentation recht schwierig. Gibt es dazu eine Info? Sender und Empfänger nutzen Firefox, liegt es evt. daran?
Vielen Dank für sachdienliche Hinweise :-)
Hi,
der benötigte Upstream steigt leider nicht linear zur Teilnehmerzahl, sondern eher exponentiell.
Man kann es mal ausprobieren, vielleicht reichen die 32 MBit/s Upload ja für 5-8 Teilnehmer.
Den Mauszeiger sehe ich schon bei Desktop-Freigaben. Allerdings verwende ich immer den Desktop-Client. Jitsi Meet und Firefox sind (momentan noch) keine gute Kombination, daher am besten Chrome oder den Desktop-Client verwenden.
Gruß,
Jan