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
Hi, very nice guide. Especially the security settings for nginx. I am a bit puzzled by this line:
>> HSTS (ngx_http_headers_module is required)
I checked on https://securityheaders.com and my website did not provide HSTS protection, even though it provides an index.html page (like in the setup above).
It is not installed available /nginx/modules_installed, I think there a no modules provided at all (Debian 10 nginx installed from ADB-package manager).
Do I have to compile nginx myself to get this working, or is there another way?
Hi,
frist of all, try to call your site in a browser with activated developer console (F12). Check, if the HSTS header is sent twice. If it is sent twice, it gets ignored by these checks. In this case, try to find out where it is set a second time and remove this configuration.
Best regards,
Jan
Hi I only found this info under ->network->mysite.com
content-encoding: gzip
content-type: text/html
date: Sun, 03 May 2020 19:19:46 GMT
referrer-policy: no-referrer
server: nginx/1.14.2
status: 200
strict-transport-security: max-age=63072000; includeSubdomains; preload;
x-content-type-options: nosniff
x-download-options: noopen
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block
It looks good to me and I only found one header entry. Does it mean this policy is working and just not recognized by the test-site?
Hi,
may be there ist any idea with my prob.
Server inst. no prob and no error .
Browser con ok.
Connection with smartphone no chance.
reg
Gerrit
Hi Gerrit,
when the connection with the browser works, it seems that Jitsi is installed correctly.
There where some problems after the last update of Jitsi. Another update came this weekend. Maybe you can update and try again?
Best regards,
Jan
Oh, I see now that all is working as intended. The browser test-page just complains about some missing headers:
Missing Headers
Content-Security-Policy Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
X-Frame-Options X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value „X-Frame-Options: SAMEORIGIN“.
Feature-Policy Feature Policy is a new header that allows a site to control which features and APIs can be used in the browser.
Hi Fred,
probably you have set the headers as shown in the article. Check if you have set the headers twice, because when settings this headers twice, these will be ignored.
You can also check in the browser console (F12) which headers are set and which are not set.
Best regards,
Jan
Hallo Jan,
ich habe mich an Deine sehr ausführlichen Anleitungen gehalten. Nun beobachte ich folgendes: ich kann zwar Meetings starten (mit „admin“ benutzer), aber wenn ich dann von einem anderen Rechner teilnehmen will, merkt dieser nicht, dass das Meeting schon gestartet ist und legt ein neues an….
Zudem kann ich kein Passwort für die Meetings vergeben.
Woran kann das liegen?
Hi Matthias,
nutzt du den Browser, oder den Browser und den Jitsi Desktop Client (hier muss die URL deines eigenen Servers noch eingetragen werden)?
Ansonsten konnte ich diesen Fehler noch nicht beobachten.
Vielleicht mal die Logs von Jitsi checken, ob hier etwas interessantes drin steht.
Gruß,
Jan
Hi Jan,
ich nutze zwei verschiedene Rechner mit verschiedenen Browsern und die IOs-App ( da habe ich den Server angepasst…).
Welche logs sollte ich checken?
VG
Matthias
Hallo Jan,
hier ein Fehler aus jicofo, aus dem ich nicht schlau werde:
Mai 07 17:44:08 systemd[1]: jicofo.service: Found left-over process 2582 (java) in control group while starting unit. Ignoring.
Mai 07 17:44:08 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
Mai 07 17:44:08 jicofo[9734]: /etc/init.d/jicofo: 428: /lib/lsb/init-functions: Cannot fork
Mai 07 17:44:08 systemd[1]: Starting LSB: Jitsi conference Focus…
Mai 07 17:44:08 systemd[1]: jicofo.service: Control process exited, code=exited status=2
Mai 07 17:44:08 systemd[1]: jicofo.service: Failed with result ‚exit-code‘.
Mai 07 17:44:08 systemd[1]: Failed to start LSB: Jitsi conference Focus.
Hi Matthias,
leider sagt mir das auch erst einmal nichts. Hast du mal versucht, sämtliche Dienste neu zu starten?
Ansonsten muss ich dich leider auf das Jitsi Forum verweisen, vielleicht kann dort jemand mit dem Fehler was anfangen.
Gruß,
Jan
Hi Jan,
danke für die Antwort. Das Neustarten hat es momentan schlimmer gemacht: ich kann nicht mal mehr mit user und pwd einen Raum eröffenen, ich fliege quasi sofort wieder raus „sorry, etwas hat nicht geklappt…“
Wenn ich das auf der Reihe habe, wende ich mich ans jitsi forum..
VG
Matthias
Hi Matthias,
wenn man direkt wieder rausfliegt, sollte aber in den Jitsi-Logs etwas zu finden sein. Gibt’s da nun andere Meldungen?
Gruß,
Jan
Hallo Jan,
vielen Dank für die ausführliche Anleitung. Leider kann ich sie an einigen Punkten aktuell nicht nachvollziehen, auch weil sie von teilweise speziellen Voraussetzungen ausgeht. Dazu weiter unten mehr.
Ich habe die Installation deshalb nach dieser Anleitung
https://www.howtoforge.de/anleitung/so-erstellen-sie-ihren-eigenen-videokonferenzserver-mit-jitsi-meet-auf-ubuntu-1804-lts/amp/
durchgeführt, da sie für mich verständlicher ist.
Tatsächlich scheint die Installation ohne Fehler durchgelaufen zu sein. Allerdings habe ich das gleiche Problem, von dem zwei Kommentatoren hier in Deinem Beitrag berichten: ich kann den Server aufrufen, einen neuen Raum anmelden, Kamera und Mikro werden sauber erkannt und es scheint alles zu funktionieren. Aber wenn ich von einem zweiten Gerät aus den selben Raum betreten möchte, wird ein neuer Raum (mit der selben URL!) erzeugt, und jeder ist für sich allein in dem Raum. Ich habe es sowohl mit zwei PCs als auch mit iOS / Android App versucht.
Im Anschluss daran habe ich noch versucht, Authentication (nach Deiner Anleitung) einzurichten – Ergebnis: auch das funktioniert nicht; man kann – wie zuvor auch – den Raum eröffnen, man muss aber trotzdem keine Credentials eingeben.
Ich habe den Eindruck, dass es eine ganz „einfache“ profane Sache ist, die noch fehlt. Aber ich weiß nicht, wo ich suchen soll.
Nun zu meiner Umgebung: ich habe eine V-Server bei Strato gehostet und dort ein Ubuntu 18.04 LTS als Grundinstallation zur Verfügung gestellt bekommen. Der Server wird über eine Sub-Domain meet.xxxx.de erreicht. Teilweise musste ich während der Durchführung der oben verlinkten Installationsanleitung Packages installieren, weil nicht alles verfügbar war (z. B. ufw). Anschließend konnte ich aber die weiteren Installationsschritte ohne Probleme durchführen.
Gerne hätte ich Deine Anleitung verwendet, aber Du gehst von bestimmten Voraussetzungen aus, die für eine Grundinstallation auf einem „blanken“ Server nicht zutreffen. Ich habe im Nachgang zu der oben verlinkten Installation versucht, Deine Anmerkungen nachzuvollziehen, kann diese aber teilweise nicht bestätigen. So müssen z. B. die Verzeichnisse für nginx definitiv nicht angelegt werden, auch gibt es ja keine vorhandene coturn Lösung die überschrieben werden könnte – insofern verwirren die beschriebenen Aktivitäten mehr, als sie einem helfen. Die Installation des Let’s Encrypt Zertifikats wird ebenfalls „sauber“ durch die beschriebene Installationsroutine vorgenommen, d. h. der Server ist über https erreichbar (ich verstehe, dass Du noch ein paar Dinge drum herum gemacht hast, aber diese überfordern mich, ehrlich gesagt). Was sich mir auch nicht erschließt ist, warum die Domain auf localhost aufgelöst werden muss. Auch ist mir nicht ganz klar, warum Du an einer Stelle von einem Router ausgehst, der über 192.168.178.1 (also vermutlich eine FritzBox) erreicht wird wenn doch an anderer Stelle von einer Sub-Domain die Rede ist (es sei denn Du hättest eine statische IP Adresse und der Server steht bei Dir daheim). Die massiven Anpassungen, die Du in der meet.meinedomain.de.config machst sind für mich praktisch nicht nachzuvollziehen. M. E. wurden auch dort die notwendigen Einträge vom Setup korrekt vorgenommen.
Alles in Allem habe ich den Eindruck, dass Du eine ältere Version von Jitsi installiert hast, die noch diverse Macken hatte. Ich habe die Installation am 18.05.2020 durchgeführt.
Vielleicht hast Du eine Idee, woran es liegt, dass nicht mehr als ein Client in einem Raum sein kann? Falls ja würde ich mich freuen, wenn Du einen Tipp hättest, der mir weiter hilft.
Viele Grüße
Raul
Hi Raul,
erst einmal danke für dein Feedback.
Ja, die hier gezeigte Installation ist schon etwas speziell, aber das hat auch einen guten Grund: Wenn du Jitsi einfach wie in der von dir verlinkten Anleitung installierst, dann richtet er automatisch nginx, coturn und Jitsi selbst ein. Allerdings ist diese Konfiguration etwas kompliziert, besonders die nginx-Konfiguration. Daher richte ich das alles lieber manuell ein (Zertifikate, nginx, cotourn) und füge dies dann in die Jitsi Meet Konfiguration ein. Dadurch ist das Setup meiner Ansicht nach sauberer – aber das ist sicherlich Geschmackssache.
Zu deinem Problem mit den getrennten Konferenz-Räumen: Das konnte ich bisher bei meinen Installationen nicht beobachten. Hier hilft wohl nur, die Logs zu durchforsten. Eine gute Anlaufstelle könnte hier auch das Jitsi Forum sein.
Gruß,
Jan
Hallo Raul,
mal kurz zur Info!
Ich habe es auch erst mit Strato probiert und hatte den identischen Fehler…nach langem suchen und Foren lesen, habe ich mich dazu entschieden, einen V-Server bei Hetzner anzumieten, seit dem läuft es.
Aber…nur die Absicherung der Instanz klappt nicht. Ich habe alle Dateien angepasst…***cfg.lua; ***config-js; sip-communicator.properties….und restart der Dienst….klappt dennoch nicht, hier suche ich noch den Fehler…
Gruß
Oliver
Hi Oliver,
seltsam, du bist nun schon der zweite, der Jitsi nicht auf einem Strato-Server betreiben kann. Obwohl Strato da nach eigener Aussage nichts blockt oder so. Aber eine interessante Beobachtung.
Bei der Absicherung der Instanz nochmal alle Schritte doppelt und dreifach kontrollieren. Da kann der kleinste Fehler dazu führen, dass das ganze nicht klappt.
Gruß,
Jan
Hier ist noch ein dritter mit Strato, bei dem es nicht läuft. Symptome ähnlich wie oben, zusätzlich ist der VServer dann dermaßen platt, dass er nicht einmal mehr SSH-Zufgriff erlaubt (und wenn, dann kommen ständig Fehlermeldungen). Ich vermute, es liegt an der Virtualisierung, die Strato für die VServer einsetzt (OpenVZ).
Hallo Rolf,
danke für den Hinweis, sehr interessant.
Hat hier vielleicht schon einmal ein Strato Kunde direkt beim Hoster nachgefragt, um hier vielleicht mal eine offizielle Aussage zu bekommen?
Gruß,
Jan
Servus zusammen!
Seit dem 31.01.2021 versuche ich Jitsi Meet verzweifelt auf einem Strato vServer 4.0 stabil zum Laufen zu bringen; ich erhalte dort die gleichen Fehler wie hier mehrfach beschrieben. Gibt es hierzu ggf. neuere Erkenntnisse wie eine Anpassung für einen Strato vServer auf Basis Ubuntu 18.04 LTS erfolgen muss oder ist ein Wechsel zu einem anderen Provider weiterhin eine mögliche Lösung? ich habe bereits Stunden an Recherche versenkt…
Vielen Dank für Euer Feedback im Voraus.
Hi Paul,
ich habe leider noch niemanden getroffen, der dies auf einem Strato-vServer zum Laufen bekommen hat. Liegt wohl an der eingesetzten Virtualisierungs-Technik (siehe einige Kommentare unter diesem Artikel).
Daher denke ich, dass nur die Einrichtung auf einem vServer eines anderen Anbieters zur Lösung führen wird.
Gruß,
Jan
Prima und danke: das ist doch eine gute Ausage, vor dem Hintergrund das ich satte zwei Tage „gebastelt“ habe und es wirklich instabil zu laufen scheint :/
Danke und beste Grüße,
Paule
Hallo Jan, vielen Dank für die tolle Anleitung.
Ich bin enttäuscht wegen der Videoübertragung. Ich habe Ubuntu 18.04 am Start mit 8GB Hauptspeicher und einem Intel® Celeron(R) CPU G3900 @ 2.80GHz × 2.
Meine Iperf-Messungen am Coturn-Port 3479 brachten schlappe 2.13 Mbit/s. Am Port 443 satte 24.5 Gbit/s. Kannst du mir erklären, warum die Bandbreite derart abweichen und ob ich das irgendwie ändern kann.
Vielen Dank und schöne Pfingsten
Hi Magnus,
was genau ist dein Problem bei der Videoübertragung? Das läuft eigentlich nicht direkt über den coturn-Port.
Ebenfalls kannst du mal die CPU-Auslastung während Konferenzen checken. Kann sein, dass das System recht schnell an der Grenze ist.
Gruß,
Jan
Seit ich den öffentlichen Zugang unterbunden habe verbindet der Server die Video nicht mehr untereinander. Es ist nur ein schwarzes Bild vom Desktop auf dem Handy sichtbar und umgekehrt.
Hat jemand irgendeine Idee, was es sein könnte, vorher hat es funktioniert.
Hi Mat,
du meinst hier sicher, dass man eine Konferenz nur noch mit User/Passwort eröffnen kann, oder?
Passen alle anderen Punkte? Hier vielleicht mal die Jitsi-Logs durchgehen, ob irgendwelche Fehler geschmissen werden.
Gruß,
Jan
Danke für den Hinweis, in einigen Log Files wurde mangelnder Zugriff über Port 5347 gemeldet. Hier habe ich die Firewall geöffnet.
Ob es das genau war… jedenfalls scheint es jetzt zu gehen.
Welches sind denn die wirklich wichtigen Log-Files, ich hatte eher planlos gesucht.
.. und generell für die tolle Anleitung. :-)
Hi,
Jitsi-Logs liegen unter /var/log/jitsi, die Logs von coturn direkt unter /var/log (wenn man es bei den Standard-Einstellungen belässt).
Aber du hast das Problem ja nun schon gefunden.
Gruß,
Jan
Hallo,
ich bin etwas irritiert zu den STUN/TURN server config-Einträgen:
wollte mit coturn beides bereitstellen unter einer subdomain: turn.meinedomain.de
und habe für diese subdomain dann das folgende tutorial umgesetzt:
https://decatec.de/home-server/nextcloud-talk-mit-eigenem-turn-server-coturn/
In diesem tut überraschte mich dann aber das:
„Wir nutzen hier allerdings ebenfalls die eigene coturn-Instanz:
stunServers: [
{ urls: ’stun:stun.meinedomain.de:5349′ }
],
Ich dachte STUN/TURN hätte ich mit dem coturn-tutorial unter turn.meinedomain.de am laufen, ein getrenntes setup von turn und stun konnte ich nicht ausmachen im tutorial..
Entsprechend kann der WebRTC trickle ICE test diesen aber nicht korrekt ansprechen:
The server stun:turn.meinedomain.de:5349 returned an error with code=701:
STUN host lookup received error.
bzw.
The server stun:stun.meinedomain.de:5349 returned an error with code=701:
STUN host lookup received error.
Portfreigaben hab ich gemacht, nextcloud z.B. ist auch normal erreichbar auf dem server.
ok, ich habs lösen können:
hab die certs für turn.meinedomain.de in einen eigenen Ordner /etc/coturn/certs kopiert und nur leserecht für user turnserver eingerichtet (damit acme.sh die certs unter letsencrypt weiter aktualisieren kann)
Das Ergebnis zeigt aber nur einen „srflx“ an ..
Time Component Type Foundation Protocol Address Port Priority
0.004 rtp host 985767174 udp c3fb3c55-5b06-446c-b651-ee65c344d00b.local 58217 126 | 30 | 255
0.895 rtp srflx 842163049 udp 192.168.usw.. 58217 100 | 30 | 255
0.895 Done
0.898
Fehlt mir da jetzt noch der STUN-Server ?
Hi Robert,
ein „srflx“ sollte da meiner Meinung nach ausreichend sein. Wenn es nicht funktioniert, kommt nämlich gar kein „srflx“.
Gruß,
Jan
Hi Robert,
die jeweiligen Domains sind in den Tutorials eigentlich nur beispielhafte Domains.
Wenn coturn auf einer Domain turn.meinedomain.de läuft, dann ist natürlich die TURN- als auch die STUN-URL turn.meinedomain.de. Das hast du vollkommen richtig erfasst.
Allerdings irritiert mich folgendes:
Die Meldung scheint ja zu bemängeln, dass er wohl die Domain turn.meinedomain.de nicht auflösen kann…
Gruß,
Jan
Das ist genau das, was ich nicht verstehe..
er gibt mir
Time Component Type Foundation Protocol Address Port Priority
0.004 rtp host 985767174 udp a5fe4707-5980-4bb4-969b-995b43ce7bd9.local 40564 126 | 30 | 255
0.690 rtp srflx 842163049 udp 192.168.usw… 40564 100 | 30 | 255
0.691 Done
0.693
und auch der ping auf turn.meinedomain.de funktioniert und trotzdem kommt diese Meldung
The server stun:turn.meinedomain.de:5349 returned an error with code=701:
STUN host lookup received error.
Hi,
könnte dies etwas hiermit zu tun haben?
Gruß,
Jan
im syslog steht:
WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided
Hallo Jan,
danke für die Anleitung. Soweit funktioniert auch alles.
Ich hab allerdings eine Frage/Problem.
In der Anleitung hab ich in der Konfigurationsdatei
nano /etc/jitsi/meet/meet.meinedomain.de-config.js
die eigenen coturn Instanz als Stun Server eingetragen.
Allerdings finde ich in der Datei die Variable „useStunTurn“ nirgends.
Muss ich das von Hand eintragen?
Gruß
-Danny-
Hi Danny,
sicher, dass es die Variable nicht gibt? Bei meinen Instanzen ist diese vorhanden.
Die Datei heißt bei jeder Instanz anders (also der Dateiname ist von der verwendeten Domain abhängig).
Gruß,
Jan
Hallo Jan,
danke für die Rückmeldung.
ich bin im Verzeichnis /etc/jitsi/meet/
dort liegt die Datei meet.*****.de-config.js
dort habe ich die Änderung des STUN Server vorgenommen.
in der p2p Sektion gibt es den Eintrag useStunTurn nicht (siehe Auszug) dort ist nur der Eintrag enabled: true
p2p: {
// Enables peer to peer mode. When enabled the system will try to
// establish a direct connection when there are exactly 2 participants
// in the room. If that succeeds the conference will stop sending data
// through the JVB and use the peer to peer connection instead. When a
// 3rd participant joins the conference will be moved back to the JVB
// connection.
enabled: true,
// The STUN servers that will be used in the peer to peer connections
stunServers: [
// { urls: ’stun:meet.*****.de:3478′ },
{ urls: ’stun:meet.*****.de:5349′ }
]
// Sets the ICE transport policy for the p2p connection. At the time
// of this writing the list of possible values are ‚all‘ and ‚relay‘,
// but that is subject to change in the future. The enum is defined in
// the WebRTC standard:
// https://www.w3.org/TR/webrtc/#rtcicetransportpolicy-enum.
// If not set, the effective value is ‚all‘.
// iceTransportPolicy: ‚all‘,
Auch die Suche ergibt keinen Treffer für die Variable.
Ich hab die ganze Installation am Wochenende nochmal Punkt für Punkt durchgeführt. aber das gleiche Ergebnis.
Der Jiitsi Server läuft aber sonst ohne Probleme.
Gruß
-Danny-
Hi Danny,
wenn es die Variable nicht mehr gibt, wurde diese evtl. in einer Version entfernt. Wenn du allerdings einen STUN-Server angibst, dann gehe ich davon aus, dass dieser auch genutzt wird.
Daher – und v.a. wenn alles andere funktioniert – würde ich hier erst einmal kein Problem sehen.
Gruß,
Jan
Guten Tag.
Ich habe hier eine Frage zum Thema „localhost“.
Sie haben ja geschrieben, dass Jitsi „localhost“ auflösen wird.
Falls ich bereits auf dem VPS WordPress hoste, ist das trotzdem möglich die WordPress-Seite und Jitsi-Meet gleichzeitig auf demselben Server zu laufen?
Danke im Voraus!
Hi,
diese „localhost-Einstellung“ ist denke ich für eine Installation einer weiteren Webanwendung nicht wirklich relevant.
Am besten „trennt“ man diese beiden Anwendungen dann durch unterschiedliche Domains, dann kann man dies auch seitens des Webservers gut auseinanderhalten.
Gruß,
Jan
Du hast im Codeschnippsel zu nginx config noch ein
„alias /etc/jitsi/meet/meet.decatec-it.de-config.js;“
stehen.
Hi Samuel,
oh ja, das hatte ich ganz übersehen. Danke für den Hinweis, wurde korrigiert.
Gruß,
Jan
Hallo zusammen.
Geht auch statt Domainname eine IP-Adresse?
Hi Moritz,
da bin ich mir nicht sicher. Allein aus Gründen der Sicherheit sollte auf jeden Fall ein HTTPS-Zertifikat zum Einsatz kommen. Da man kein gültiges Zertifikat auf eine IP, sondern nur auf eine Domain ausstellen kann, wird es hier wohl schwierig.
Ob sich Jitsi Meet dann mit einer IP statt einer Domain zufrieden gibt, kann ich dir nicht sagen. Am besten einfach mal ausprobieren und dann eben ein selbst signiertes Zertifikat generieren.
Gruß,
Jan
Hallo Jan,
vielen dank für die übersichtliche und saube strukturierte anleitung!
Ich würde gern die jitsi Installation mit 3 Domains betreiben.
meet.aaa.de
meet.bbb.de
meet.ccc.de
MIt einer läuft alles super, beokmme es aber nicht auf mehrere erweitert.
hab etwas dazu im jitsi forum gefunden –> https://community.jitsi.org/t/multiple-domains-under-1-install/21361/2
in nginx habe ich die weiteren Domains angelegt indem ich meet.aaa.de kopiert und enstprechend geändert habe.
Letsencrypt zertifikate sind auch angelegt und verknüpft.
vermute es hat was mit den HEaders und Cors zu tun…
hast du evtl einen tipp dazu?
Gruß Uwe
Hi Uwe,
ja, mit CORS liegst du schon ganz gut. Versuch mal, in der Prosody-Konfiguration den Wert für
cross_domain_boshauftruezu setzen. Das war in meinen Versuchen notwendig, wenn über mehrere Domains auf die gleiche Instanz zugegriffen werden sollte.Gruß,
Jan
Hallo Jan,
habe es mit dem jitsi forum hinbekomen.
in der standard domain muss in der nginx conf (z.B. /etc/nginx/meet.haupdomain.de.conf) im
# BOSH abschnitt die zeile von
proxy_set_header Host $http_host;
nach
proxy_set_header Host meet.haupdomain.de;
geändert werden.
und in der /etc/jitsi/meet/meet.haupdomain.de-config.js muss
bosh: ‚/server.example.local/http-bind‘,
nach
bosh: ‚///http-bind‘,
geändert werden.
in der Nginx conf für die zusätzliche(n) domains wird nur server_name und die zertifikatspfade auf die zusatzdomain angepasst, alles andere is tidentisch.
Hi Uwe,
danke für die Info. Das CORS für Bosch war nun nicht anzupassen?
Gruß,
Jan
nope, nur die zwei Änderungen an den bestehnden configs und halt je zusatzdomain ne neue nging-vhost-conf
Hallo und Vielen Dank für deine Tutorials, ich bin wirklich ein großer Fan
Ich muss gestehen das ich Jitsi , noch nicht, installiert habe jedoch plane dies zu tun. Deine Anleitung ist mir dabei eine sehr große Hilfe, auch im Bezug zur Wahl der Mittel.
Eine Frage habe ich jedoch in Bezug auf die Sicherheit für den nicht öffentlichen Zugang.
Du hast das Admin-Passwort in Klartext in der Config übernommen. Wäre es nicht besser dies, z.B., mit GnuPG zu verschlüsseln?
Und wenn wie müsste dann die Config angepasst werden.
Wie gesagt ich bin noch am Planen und habe noch nichts Installiert denke mal so in der Art könnte das Passwort verschlüsselt werden.
[code]
# GnuPG installieren
apt install gnupg2
# überprüfen ob GnuPG aktiv ist
gpg-agent -s –daemon –write-env-file –use-standard-socket
# Verschlüsselung Key erstellen
gpg –full-generate-key
# nur als Beispiel (1 – 4096 – 0 – y)
# entsprechend anpassen (Namer – BenutzernameAdmin – Firma)
# Keyphrase 2 mal eingeben – ein-wirklich-starkes-Stück
# Passwortfile für Jitsi Meet erstellen Admin Benutzernamen eingeben
# !! wichtig Passwort des Jitsi Admin’s direkt einfügen es gibt keinen Eingabeprompt !!
# !!nach dieser Eingabe mit Enter bestätigen und im Anschluss CTRL-D (STRG-D) drücken !!
gpg –encrypt -o ~/.jitsi-password.gpg -r BenutzernameAdmin –
# eigenes PASSWORT eingeben
zu-verbergendes-Passwort
[/code]
soweit so gut, denke ich mal, aber wie binde ich das jetzt in die Jitsi Config ein und ersetze diese Zeile.
[code]
prosodyctl register JitsiAdmin meet.meinedomain.de ‚mEinPAssw0rt‘
[/code]
Hier müsste sicherlich erst mal der „user BenutzernameAdmin“ in der Config deklariert werden. Leider bin ich aber noch nicht dahinter gekommen wie ich „prosodyctl register“ anpasse um
[code]
gpg2 –no-tty -q -d ~/.jitsi-password.gpg
[/code]
zu übernehmen anstelle des Passworts.
Könntest du mir da einen Denkanstoß geben oder vll. einen Lösungsvorschlag.
Vielen Dank
Hi Peter,
das Passwort wird ja nicht in einer Config hinterlegt, sondern bei Prosody registriert. Wo dieses Passwort letzten Endes gespeichert wird, spielt hier erst einmal keine Rolle.
Klar, wenn jemand SSH-Zugriff mit Root-Rechten auf den Server erlangt, dann kann er sicher auch diese Passwörter auslesen, aber dann ist ja das gesamte System kompromittiert. „Von außen“, also per HTTPS(S) kommt man an diese Passwörter nicht ran.
Daher kann ich hier keinen direkten Handlungsbedarf feststellen, bzw. sehe auch kein Sicherheitsrisiko.
Gruß,
Jan
Hallo Jan, warum muss Port 4443 TCP im Router geöffnet werden, wenn in UFW der Port nicht geöffnet wird?
Danke! Horst!
Hi Horst,
ich denke, da hat sich im Text ein kleiner Fehler eingeschlichen. Die „Codebox“ ist jedoch korrekt.
Ich habe das gleich mal korrigiert. Danke für den Hinweis!
Gruß,
Jan
Hallo Jan, dann komme ich zu meiner nächsten Frage, ich hätte gedacht das Du das vergessen hast. https://www.kuketz-blog.de/jitsi-meet-server-einstellungen-fuer-einen-datenschutzfreundlichen-betrieb/ in dieser Anleitung zum Thema Turn/Stun auf Port 443 gab es ein Link zu Deiner Installation. Ich hatte gedacht, dass Du den 4443 Port vergessen hast und der Turn Server diesen dann von Anfragen auf Port 443 TCP auf 4443 TCP auf den Jitsi leiten würde.
https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-manual
Grundsätzlich hört der Jitsi für eine Video Bridge doch auch auf TCP 4443??? Danke!
Hi Horst,
laut offizieller Doku ist Port 4443 nicht notwendig. TURN und STUN arbeiten bei mir beide auf Port 5349 (TCP/UDP). In Umgebungen mit besonders strikten Firewalls kann es empfehlenswert sein, coturn auf Port 443 laufen zu lassen. Dies erfordert dann aber einen weiteren Server, da 443 ja schon von nginx belegt ist.
Gruß,
Jan
Hallo Jan,
ja dafür ist laut Kuetz dann der externe Stun/Turn Server für zuständig, dann müsste der Port vermutlich auf 4443 TCP offen sein. Da Stun vielleicht nur TCP zu TCP oder UDP zu UDP umleiten kann?
Er hat nur auf Deine Anleitung verwiesen, daher bin ich hier gelandet. Ok, dann hast Du das vermutlich noch nicht probiert?
Hi Horst,
ich glaube ich verstehe dein Anliegen noch nicht so ganz. Auf der Seite des coturn muss eben der Port offen sein, den coturn nutzt (bei mir immer 5349). Seitens Jitsi-Meet müssen hier keine weiteren Ports für die TURN-Verbindung geöffnet werden, da diese in diesem Kontext ja nur ausgehend sind.
Ob die Verbindung zum coturn ordnungsgemäß funktioniert (zumindest bzgl. STUN), kann man einfach über diese Seite testen.
Gruß,
Jan
Hallo – funktioniert bei dir die Funktion der Sprecherstatistik? Meine Jitsi Instanz läuft ganz ordentlich. Ab und zu werden einige Videos einfach schwarz – die Verbindung bliebt aber… Die Statstik, wer wie lange gesprochen hat bleibt aber immer auf 0…
Hi Ralf,
auf dieses Feature habe ich noch gar nicht geachtet. Ich werde aber mal in der nächsten Konferenz darauf achten.
Gruß,
Jan
Haben noch andere das Problem, dass in einem meeting mit 5-8 Personen oder mehr die Videoübertragung aussetzt. Bei einigen bleiben alle Gesprächsteilnehmer sichtbar, bei anderen verschwindet 80% der Teilnehmenden. Es ist ein ständiger unangenehmer Wechsel. Das Problem wird z.B. auch hier beschreiben
https://community.jitsi.org/t/black-screens-that-appear-and-disappear/91223
Hi,
dieses Verhalten konnte ich noch nicht beobachten. Im Foren-Thread sind ja sehr wenige Infos zu finden.
Manifestiert sich dieses Problem auch in irgend einer Weise in den Logs – sowohl Server-, als auch Client-seitig (Browser-Console)?
Gruß,
Jan
Hallo Jan – Was ich im jvb.log immer wieder finde ist sind Warnungen zu:
MargingDatagram.Socket und TCC packet contained reseived … Couldn’t finde packet detail for the seq nums…
Wo auf dem Server müsste ich noch suchen – oder kannst du damit was anfangen?
Hi,
der Fehler sagt mir leider gar nichts. In der Ordner-Struktur, wo du die jvb.log gefunden hast, sollten noch mehr Logs von Jitsi zu finden sein.
Ich würde aber erst einmal die Browser-Console checken. Kann sein, dass da was sinnvolleres ausgegeben wird.
Gruß,
Jan
Hallo Jan,
vielen Dank für deine tolle Arbeit.
Ich habe eine Frage bezüglich Domain und Subdomain, da ich sowohl unter meet.meinedomain.de als auch meinedomain.de die Jitsi Instanz erreiche. Ich würde gerne den Zugriff auf meinedomain.de unterbinden oder direkt weiterleiten auf meet.meinedomain.de.
Kannst du mir hierzu einen Tipp geben.
Hi,
wie hast du es umgesetzt, dass eine Instanz unter zwei Domains erreichbar ist?
Die pragmatische Lösung wäre es nun sicher, einfach per vHost den Zugriff auf meinedomain.de zu unterbinden.
Gruß,
Jan
Hallo Jan,
es bedarf gar nicht vieler Änderungen, um eine Jitsi-Instanz auf 2 oder mehr Domains laufen zu lassen. Um genau zu sein, sind es nur 2 Anpassungen.
nano /etc/jitsi/meet/meet.meinedomian.de-config.js
Folgendes ändern:
// BOSH URL. FIXME: use XEP-0156 to discover it.
bosh: ‚//meet.meinedomain.de/http-bind‘,
ändern in:
// BOSH URL. FIXME: use XEP-0156 to discover it.
// bosh: ‚//meet.meinedomain.de/http-bind‘,
bosh: ‚///http-bind‘,
Dabei muss die ursprüngliche Zeile natürlich nicht auskommentiert werden, sondern kann auch ersetzt werden. Ich behalte den Ursprung nur gern, um Dinge problemlos rückgängig machen zu können – schadet ja nicht.
In jedem vHost einer Domain/Subdomain, die nicht die Installations-Domain von Jitsi ist, muss Folgendes angepasst werden:
nano /etc/nginx/conf.d/meet.meinedomain2.de.conf
Folgendes ändern:
# 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;
}
ändern in:
# BOSH
location = /http-bind {
proxy_pass http://localhost:5280/http-bind;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $meet.meinedomain.de;
}
Dabei ist meet.meinedomain.de die Domain unter der Jitsi bei der Installation ursprünglich eingerichtet wurde.
Ich habe das Ganze dann etwas eleganter gelöst, um nicht in jedem vHost die Jitsi-Konfiguration angeben zu müssen – mit einem Snippet (/etc/nginx/snippets/jitsi-meet.conf) und einem Include (include /etc/nginx/snippets/jitsi-meet.conf;) im vHost der gewünschten Domain.
Grüße aus Leipzig
Steffen
Hi Steffen,
danke für den Hinweis. Habe zwar noch keine „Multiple-Domain-Instanz“ aufgesetzt, aber ist vielleicht auch für andere Leser ganz interessant.
Gruß,
Jan
Hallo Jan,
vor Kurzem gab es ein Update für Jitsi. Dabei ist eine wichtige Anpassung unter Ubuntu 18.04 notwendig. Es wird ein neues Repository benötigt um nicht in einen Fehler zu laufen, da Ubuntu 18.04 die benötigte Programmversion .11 von Prosody nicht mehr zur Verfügung stellt.
Folgende Befehle helfen Update-/Installationsprobleme zu vermeiden:
echo deb http://packages.prosody.im/debian $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list
wget https://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add –
apt update & apt upgrade
Grüße aus Leipzig
Steffen
Hi Steffen,
genau, mit diesen Zeilen nutzt du Prosody aus den offiziellen Paketquellen von Prosoody und erhälst so neuere Versionen, als wenn du Prosody aus den Ubuntu-Paketquellen nutzen würdest.
Bisher war dies aber nur notwendig, wenn man recht neue Features von Jitsi-Meet nutzen wollte, die auf einer neueren Version von Prosody basierten.
Ich habe den Artikel aber gleich mal aktualisiert (basiert nun auf Ubuntu 20.04 mit dem optionalen Schritt, die Prosody-Paketquellen hinzuzufügen).
Danke für den Hinweis!
Gruß,
Jan
Hallo zusammen,
danke für diese Anleitung.
Leider habe ich hier Probleme.
Öffentlichen Zugang unterbinden (“Secure Domain”)
OS Debian 11
ich finde diese Datei nicht.
/etc/jitsi/jicofo/sip-communicator.properties
Kennt einer das Problem und wo tragen die Debian user den Befehl rg.jitsi.jicofo.auth.URL=XMPP:jitsi-meet.example.com
ein ?
Danke
Hi,
gibt es denn das Verzeichnis /etc/jitsi/jicofo? Wenn ja, dann lege diese Datei einfach neu an und trage hier die entsprechenden Inhalte ein.
Gruß,
Jan
Hallo Jan,
nach dem Update des Servers erschien bei versuchtem Hinzufügen eines Users über ‚prosodyctl register‘ folgende Fehlermeldung:
Prosody was unable to find lua-unbound
This package can be obtained in the following ways:
Debian/Ubuntu | sudo apt install lua-unbound
luarocks | luarocks install luaunbound
Source | https://www.zash.se/luaunbound.html
Old DNS resolver library will be used
More help can be found on our website, at https://prosody.im/doc/depends
>>>>>> Beim Versuch, lua-unbound per apt install zu installieren, kam dann:
Package lua-unbound is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package ‚lua-unbound‘ has no installation candidate
Ich habe über ‚prosodyctl about‘ herausbekommen, dass prosody 0.12 installiert ist und dann versucht, ein Downgrade auf 0.11 durchzuführen, weil 0.12 offenbar in dem Zusammenhabg nicht funktioniert. Seitdem geht nix mehr. >>>Failed to start prosody.service: Unit prosody.service is masked. ’systemctl unmask prosody‘ bringt nichts
Der Fehler ist auch hier beschrieben:
https://community.jitsi.org/t/prosody-was-unable-to-find-lua-unbound/113212/9
Hast du einen Tipp? Sollte ich evt. die ganze Jitsi-Installation plattmachen wie hier beschrieben https://github.com/jitsi/jitsi-meet/issues/2663#issuecomment-376484424.
Nur was kommt dann, wenn ich wieder bei prosody 0.12 und lua 5.3 lande?
Vielen Dank im Voraus
Stefan
Hi Stefan,
die Zeile „Old DNS resolver library will be used“ klingt so, als ob das keine Fehlermeldung, sondern eher eine Warnung ist. Kann es sein, dass der User trotzdem erfolgreich angelegt wurde?
Jitsi scheint aber echt Probleme mit Prosody 0.12 zu haben. Wie hast du das Downgrade durchgeführt? Ich würde erst einmal die Prodody-Config sichern, dann das Paket mit „apt remove …“ entfernen und dann die neuste 0.11er Version installieren. Dann die Config zurück spielen. Das sollte dann auf jeden Fall das Problem mit dem „masked“ lösen.
Gruß,
Jan
Hi Jan,
vielen Dank für deine schnelle Antwort! Ich bin aufgrund des zeitlichen Drucks Beiträgen im Jitsi-Forum https://community.jitsi.org/t/how-to-downgrade-prosody/112872/9 gefolgt und habe das mit sudo apt update
sudo apt install prosody-0.11 erledigt, weil auf 0.11 auf einem anderen Server in Kombination mit lua 5.3 einwandfrei läuft. Der Downgrade-Versuch war aber ein ziemlicher Schuss in den Ofen. Hab‘ leider hier leider mit y bestätigt:
Configuration file ‚/etc/prosody/prosody.cfg.lua‘
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version.
Die Frage ist nun, ob ich durch Ändern der Dateien in den folgenden directories noch was retten kann oder besser die komplette Jitsi-Installation lösche und neu ansetze?
# Prosody directories
Data directory: /var/lib/prosody
Config directory: /etc/prosody
Source directory: /usr/lib/prosody
Plugin directories:
/usr/lib/prosody/modules/
Bei der zerschossenen Instanz handelt es sich um meinen „Labor-Server“, den ich auch Bekannten zur Verfügung stelle. Richtig nervig ist die Vorstellung, dass prosody auch auf dem großen Schulserver nach einem Update auf 0.12 spinnt und ich dann die gleichen Probleme hätte.
Gruß Stefan
Hi Stefan,
wenn es sich nur um eine „Test-Instanz“ handelt, würde ich vermutlich eher dazu tendieren, den Server nochmal von vorn aufzusetzen.
Da die Probleme mit Prosody 0.12 ja anscheinend schon bekannt sind, wird dies bei einem Jitsi-Update wohl (hoffentlich) berücksichtigt.
Auf jeden Fall würde ich vor einem Update ein komplettes Backup des Servers anfertigen und in der Zwischenzeit sämtliche Jiti- und andere benötigten Pakete (wie z.B. Prosody) per apt-makt „on hold“ setzen.
Gruß,
Jan
Den Server noch mal von vorne aufzusetzen, meint dann auch wirklich, die ganze Kiste platt zu machen. Ich habe das ganze WE damit verbracht, zu versuchen, nur jitsi und prosody auf die vorgegebene offizielle Art und Weise auf dem bestehenden Server löschen und neu installieren zu wollen. Allein prosody lässt sich auch mit apt purge –auto-remove nicht richtig deinstallieren und anschließend taucht immer wieder irgendwo auf wieder auf. Selbst wenn man es schafft, die Neuinstallation nach dem manuellen Löschen aus irgendwelchen Verzeichnissen ohne Fehlermeldung hinzubekommen, lassen sich z.B. anschließend Kamera und Mikro nicht aktivieren etc. Beim Googlen der Fehlermeldungen stößt man dann auch reihenweise auf Beiträge im Forum, die dazu raten, den ganzen Server neu aufzusetzen. …Da auf dem Server noch eine produktive Nextcloud liegt, habe ich den Plan jetzt erst einmal beerdigt und mir noch einen kleinen VPS-Server für Jitsi dazugemietet. Den mache ich dann, wenn sich so etwas wiederholt gleich platt und fange wieder von vorne an, das spart dann wenigstens Nerven. Was für ein Albtraum…
Hi Stefan,
das klingt ja wirklich nicht gerade toll. Von der NC hätte man ja ein Backup machen können und dann nach dem Plattmachen des Servers wieder neu aufspielen können. Ist aber so oder so mit etwas mehr Aufwand verbunden.
Bist du eigentlich auf Jitsi fixiert? Wenn z.B. schon eine NC vorhanden ist, könnte man ja NC Talk als Videokonferenz-Lösung mal ausprobieren.
Gruß,
Jan
Hallo Jan,
Klasse Anleitung, vielen Dank!
Möchte dies gerne umsetzen, habe dazu allerdings eine Frage: inzwischen gibt es ja schon ubuntu 22.04 LTS, passt die Anleitung damit trotzdem noch?
Danke,
Gruß Daniel