Für Nextcloud ist schon seit einiger Zeit eine Erweiterung als App verfügbar, mit der Chats und (Video-)Telefonate über die eigene Cloud geführt werden können: Nextcloud Talk.
Im Normalfall muss man dafür einfach die App im Nextcloud App Store herunterladen und kann sofort loslegen, mit anderen Nutzern der Cloud zu kommunizieren. Dank der Verfügbarkeit von mobilen Apps für Android und auch iOS kann diese Lösung auch als Alternative zu den bekannten Kommunikation-Apps (wie z.B. WhatsApp) genutzt werden. Das Hauptargument für Nextcloud Talk ist dabei sicherlich, dass Chats und (Video-)Telefonate komplett verschlüsselt über die eigene Nextcloud-Instanz ablaufen und so vor den neugierigen Blicken von Konzernen geschützt sind.
Dennoch treten bei Nextcloud Talk oftmals Probleme auf, wenn sich die genutzten Endgeräte nicht im selben Netzwerk befinden. Hier können dann keine (Video-)Telefonate geführt werden, da sich die Geräte einfach nicht finden können.
Damit über Nextcloud Talk jederzeit problemlos kommuniziert werden kann, ist ein eigener TURN-Server notwendig. Mit coturn ist ein solcher auch unter Ubuntu verfügbar. Dieser Artikel beschreibt daher die Installation und Konfiguration von coturn, um optimal mit Nextcloud Talk zusammen zu arbeiten.
Als Basis dient wie immer der Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.
Wichtig: Auch wenn ein eigener TURN-Server bei Nextcloud Talk zum Einsatz kommt, sind dennoch Videokonferenzen mit maximal 4 bis 6 Teilnehmern möglich. Für mehr Teilnehmer ist dann ein externer „Signaling Server“ notwendig, den man allerdings nur in Verbindung mit einer Nextcloud Enterprise Subscription nutzen kann.
Wenn an die Videokonferenz-Lösung höhere Ansprüche gestellt werden, könnte Jitsi Meet eine geeignetere Lösung sein (siehe Artikel Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx)
- 05.03.2022:
- Hinweise für die Nutzung von Port 443 mit coturn.
- 14.07.2021:
- Anpassungen der Pfade der SSL-Zertifikats-Dateien, damit diese zu den restlichen Artikeln passen.
- Anpassen der Rechte für den privaten SSL-Key, damit coturn diesen lesen kann.
- 08.01.2021:
- Optionen lt-cred-mech und no-loopback-peers aus der coturn-Konfiguration entfernt.
- 12.04.2020:
- Hinweis zu den Einschränkungen von Nextcloud Talk hinzugefügt.
- 03.02.2020:
- Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.
Inhalt
Probleme mit Nextcloud Talk mit eigenem STUN/TURN-Server lösen
Nextcloud Talk basiert auf WebRTC. Die bei der Kommunikation beteiligten Endgeräte bauen dabei eine direkte Peer-to-Peer-Verbindung auf.
Im gleichen Netzwerk (LAN) ist dies kein Problem, hier müssen alle Endgeräte lediglich WebRTC unterstützen.
Wenn sich die Geräte in unterschiedlichen Netzwerken befinden, müssen die Geräte sowohl ihre interne, also auch ihre externe IP-Adresse kennen. Diese Umsetzung ist die Aufgabe eines STUN-Servers (Session Traversal Utilities for NAT). Für Nextcloud Talk ist ein eigener STUN-Server verfügbar (stun.nextcloud.com:443), daher sollte dies auch kein Problem darstellen.
Wenn nun allerdings Firewalls mit im Spiel sind, kann der STUN-Server die „Übersetzung“ der Adressen nicht mehr leisten. In diesen Fällen spricht man von einem Symmetric NAT: Hier wird durch die Firewall verhindert, dass von außen (d.h. aus dem Internet) initiierte Verbindungen in das lokale Netzwerk möglich sind. In diesem Szenario ist dann ein TURN-Server (Traversal Using Relays around NAT) notwendig, über den sämtliche Verbindungen geleitet werden.
Diese Thematik ist durchaus komplex, aber vereinfacht kann man sagen, dass man einen TURN-Server benötigt, wenn die Verbindung zwischen Geräten in unterschiedlichen Netzwerken nicht aufgebaut werden kann (z.B. PC im Heimnetzwerk, Smartphone in Mobilfunknetz). Im Heimnetzwerk-Bereich ist dies vermutlich immer der Fall.
Unter Ubuntu ist coturn als quelloffene Implementierung eines STUN/TURN-Servers verfügbar.
Hinweis: coturn läuft auf einem definierten Port (in diesem Artikel Port 5349). Dies ist v.a. praktisch, da coturn bei diesem Port mit keinen anderen Diensten in Konflikt gerät. Dieser Port wird dann von den Clients (also den Teilnehmern von Nextcloud Talk Konferenzen) genutzt. Nun kann es allerdings vorkommen, dass der Port 5349 Client-seitig nicht genutzt werden kann, z.B. wenn ein Teilnehmer hinter einer restriktiven (Firmen-)Firewall sitzt, die ausschließlich Traffic auf Port 443 zulässt.
Um solchen Problemen vorzubeugen, ist es empfehlenswert, coturn auf Port 443 laufen zu lassen. Dieser Port ist dann allerdings für andere Anwendungen blockiert, so dass es damit z.B. nicht mehr möglich ist, auf dem gleichen Server einen Webserver (auf Port 443) zu betreiben. Wenn man coturn also auf Port 443 laufen lassen will, braucht man dazu entweder einen exklusiven Server für coturn oder muss mit einem evtl. vorhandenen Webserver auf einen anderen Port (z.B. 444).
Installation und Konfiguration coturn
coturn kann ganz einfach auf dem gleichen System installiert werden, auf dem auch schon Nextcloud läuft.
Zunächst bringen wir das System auf den neusten Stand:
apt-get update && apt-get upgrade -V
Anschließend kann coturn auch schon installiert werden, da es bereits Teil der Ubuntu-Paketquellen ist:
apt-get install coturn
Nach der Installation muss coturn nun nur noch konfiguriert werden, damit eine optimale Zusammenarbeit mit Nextcloud Talk gewährleistet ist.
Dazu wird coturn erst einmal aktiviert. Dies geschieht in folgender Datei:
nano /etc/default/coturn
Hier muss folgende Zeile eingefügt werden. Diese ist nach der Installation bereits vorhanden, ist allerdings auskommentiert. Daher entfernen wird einfach das Zeichen ‚#‘ am Anfang der Zeile:
TURNSERVER_ENABLED=1
Als nächstes werden die Einstellungen von coturn bearbeitet.
Diese befinden sich in folgender Datei:
nano /etc/turnserver.conf
Hier müssen die folgenden Werte angepasst werden. Die meisten Werte sind hier bereits vorhanden, allerdings auskommentiert. Auch hier entfernen wir die Raute (‚#‘) vor der entsprechenden Zeile.
- tls-listening-port=5349
- fingerprint
- use-auth-secret
- static-auth-secret=<secret>
- realm=meinedomain.de
- total-quota=100
- bps-capacity=0
- stale-nonce=600
- cert=/etc/letsencrypt/meinedomain.de/rsa/cert.pem
- pkey=/etc/letsencrypt/meindomain.de/rsa/key.pem
- cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384″
- no-multicast-peers
- dh-file=/etc/nginx/dhparams/dhparams.pem
- no-tlsv1
- no-tlsv1_1
- no-stdout-log
Zu den angegebenen Werten hier noch ein paar Erklärungen:
- tls-listening-port: Hier verwende ich den Standard-Port für TLS-Verbindungen zu coturn (5349). Hier könnte man auch einen anderen Port angeben. Diesen sollte man sich merken, da man diesen nachher in der Firewall freischalten muss.
Für maximale (Client-)Kompatibilität ist hier der Port 443 empfehlenswert. In diesem Fall darf dieser Port aber von keiner anderen Anwendung (z.B. Webserver) genutzt werden. - static-auth-secret: Dies ist ein Passwort, welches zur Nutzung des TURN-Servers benötigt wird. Dies ist ein Sicherheitsmerkmal, so dass kein Dritter ohne Kenntnis dieses Passwortes den TURN-Server verwenden kann. Dieses Passwort muss man sich nicht merken und wird später nur in den Nextcloud-Einstellungen hinterlegt, daher lässt man sich dies am besten einfach durch folgenden Befehl generieren: openssl rand -hex 32
- cert/pkey/dh-file: Dies sind die SSL-Zertifikate bzw. Diffie-Hellman-Parameter, die für die verschlüsselte Verbindung über TLS benötigt werden. Hierzu verwenden wir einfach die bereits vorhandenen Zertifikate für die eigene Domain (siehe hier und hier).
- cipher-list: Legt die Cipher-Suite für die TLS-Verbindung zum TURN-Server fest. Hier kann die Cipher-Suite angegeben werden, die auch schon der Webserver nginx verwendet (hier heißt die Variable ssl_ciphers, siehe hier).
Nach diesen Anpassungen sollte noch sicher gestellt sein, dass der (private) SSL-Key die richtigen Berechtigungen hat, damit coturn diesen auch lesen kann:
chmod 644 /etc/letsencrypt/meinedomain.de/rsa/key.pem
Am Schluss wird coturn neu gestartet, damit die Änderungen übernommen werden.
service coturn restart
Hinweis für die Nutzung von Port 443: Hier kann coturn standardmäßig nicht den Port 443 binden. Hier muss noch die systemd-Unit angepasst werden, so dass auch Ports kleiner 1024 genutzt werden können:
cp /lib/systemd/system/coturn.service /lib/systemd/system/coturn.service.backup sed -i -e 18i"AmbientCapabilities=CAP_NET_BIND_SERVICE" /lib/systemd/system/coturn.service systemctl daemon-reload
Anschließend wird coturn neu gestartet und läuft nun auf Port 443:
service coturn restart
Portfreigaben einrichten
Nach der Einrichtung des TURN-Servers muss nun noch eine Portfreigabe eingerichtet werden, damit coturn auch „von außen“ erreichbar ist.
Wichtig ist hier der Port, der bei der Variable tls-listening-port in der coturn-Konfiguration angegeben wurde. In diesem Beispiel verwende ich dazu den Standard-Port 5349.
Zunächst muss hier eine entsprechende Portweiterleitung im Router eingerichtet werden. Das genaue Vorgehen unterscheidet sich hier von Router zu Router, daher kann an dieser Stelle keine detaillierte Anleitung erfolgen. Hier sollte man aber alle notwendigen Informationen auf den Hersteller-Seiten finden (so z.B. auf den AVM Hilfeseiten, wenn man eine FritzBox im Einsatz hat). Wichtig ist hier, dass die Freigabe für die beiden Protokolle TCP und UDP angelegt werden. Dazu ist meistens das Anlegen von zwei Freigaben notwendig, hier am Beispiel einer FritzBox:
Wenn darüber hinaus auch noch eine Firewall auf dem System installiert ist, auf dem coturn eingerichtet wurde, so muss auch hier eine Freigabe erfolgen. Auf vielen Systemen wird wohl ufw (uncomplicated firewall) eingerichtet sein. Hier erfolgt die Freigabe dann über folgende Befehle:
ufw allow 5349/tcp ufw allow 5349/udp
Nextcloud Talk mit eigenem STUN/TURN-Server
Nun kann Nextcloud Talk mit dem eigenen STUN bzw. TURN-Server betrieben werden.
Zunächst muss – falls noch nicht geschehen – die App Talk aus dem Nextcloud App Store heruntergeladen werden. Diese befindet sich in der Kategorie Kommunikation.
Nach der Installation der App muss diese noch konfiguriert werden, damit diese coturn als STUN bzw. TURN-Server nutzt. Die dazugehörigen Optionen findet man in den Admin-Einstellungen von Nextcloud unter dem Punkt Talk.
Zunächst fügen wir mit der Plus-Schaltfläche einen zusätzlichen STUN-Server hinzu:
meinedomain.de:5349
Die Einstellungen für den TURN-Server sehen dann folgendermaßen aus:
- URI: meinedomain.de:5349: Der Port wurde zuvor in der coturn-Konfiguration (tls-listening-port) hinterlegt.
- Gemeinsames Geheimnis: Hier muss das Passwort angegeben werden, welches bei der Konfiguration von coturn als Variable static-auth-secret hinterlegt wurde.
- UDP und TCP: Nextcloud Talk soll hier für maximale Kompatibilität sowohl TCP- als auch UDP-Verbindungen nutzen.
Unter Signalisierungsserver sind keine Eingaben notwendig.
Die Konfiguration kann nun ganz einfach mit der entsprechenden Schaltfläche getestet werden (siehe Pfeil oberes Bild). Hier sollte dann nach einem kurzen Augenblick auch eine Erfolgsmeldung erscheinen:
Chats und (Video-)Telefonie über die eigene Nextcloud
Ab sofort können über Nextcloud Talk Chats, Telefonate und auch Video-Telefonate geführt werden. Dies ist auf den verschiedensten Endgeräten möglich: Zum einen kann Nextcloud Talk ganz einfach im Browser verwendet werden. Dazu in der oberen Menüleiste einfach auf das Talk-Symbol klicken. Nun noch den passenden (Nextcloud-)Kontakt auswählen und schon kann es losgehen.
Richtig interessant wird die Sache allerdings mit mobilen Geräten, wie z.B. Smartphones. Hier stehen App sowohl für iOS, als auch für Android bereit:
Der Funktionstest des eigenen TURN-Servers erfolgt am besten mit einem Smartphone: Wenn dieses nicht mit dem Heimnetzwerk, sondern mit dem Mobilfunknetz verbunden ist, sollten sowohl Chats, auch als (Video-)Telefonate mit einem Gerät im Heimnetzwerk problemlos möglich sein.
Troubleshooting
Falls Probleme mit Nextcloud Talk auftreten, sollte zunächst einmal die grundsätzliche Konfiguration durch die entsprechende Schaltfläche in den Admin-Einstellungen zu Talk überprüft werden (siehe Screenshot weiter oben). Anschließend kann es auch sinnvoll sein, die Nextcloud-Logs zu überprüfen. Diese findet man in der Admin-Oberfläche von Nextcloud unter dem Punkt Protokollierung.
Wenn im Nextcloud-Log keine Einträge vorhanden sind, die sich mit Talk in Verbindung bringen lassen, sollte die Funktion von coturn überprüft werden. Die Log-Dateien von coturn befinden sich im Verzeichnis /var/log. Die gesuchten Log-Dateien beginnen alle mit turn_ und beinhalten eine Datumsangabe im Dateinamen, z.B. turn_1352_2018-11-08.log. In diesen Log-Dateien sollte dann zumindest ein Hinweis zu finden sein, warum es zu Problemen gekommen ist.
Fazit
Im Heim-Bereich funktioniert Nextcloud Talk leider nicht immer out-of-the-box – mit dem Aktivieren der App ist es hier meistens nicht getan. Allerdings kann mit coturn recht einfach ein eigener STUN/TURN-Server in Betrieb genommen werden. Der entsprechende Konfigurations-Aufwand hält sich hierfür auch in Grenzen.
Mit Hilfe des eigenen TURN-Servers ist es nun aber möglich, über die eigene Cloud Chats und (Video-)Telefonate zu führen. Dieses Konzept ist im Vergleich zu den bekannten Apps (wie z.B. WhatsApp) besonders interessant, da die Kommunikation ausschließlich verschlüsselt über die persönliche Cloud abläuft, ohne dass hier Konzerne wie Google oder Facebook „mitlesen“ können.
Weiterführende Artikel
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
- Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx
Links
- Nextcloud Homepage (englisch)
- Übersichtsseite Nextcloud Talk (englisch)
- Nextcloud Talk im Nextcloud App Store
- WebRTC (Wikipedia)
- Peer-to-Peer (Wikipedia)
- Netzwerkadressübersetzung (Wikipedia)
- Session Traversal Utilities for NAT (Wikipedia)
- Traversal Using Relays around NAT (Wikipedia, englisch)
- coturn (GitHub)
Hi Jan, zur Info:
den Wert no-loopback-peers ist nun geändert worden in der aktuellen Version.
# (To avoid any security issue that allowing loopback access may raise,
# the no-loopback-peers option is replaced by allow-loopback-peers.)
Hi Timo,
hast du hier vielleicht einen Link für mich o.ä.?
Gruß,
Jan
https://github.com/coturn/coturn/blob/ae2ee1f4e4f4f4119425e3d890a7f6ca44b57d0b/examples/etc/turnserver.conf#L604
LG Chris
Hallo. Sehr gute Anleitung! Würde dies gerne auf meinem HomeLab über Nginx Reverse Proxy betreiben. Nextcloud läuft so sehr gut. Den eigenem STUN/TURN-Server würde ich auch gerne hinter den Reverse Proxy bringen. Den Virtualhost für STUN sowie TURN im Reverse Proxy bringe ich nicht hin. Bin insbesondere deshalb daran interessiert diese Server selber zu hosten, da diese neben Nexcloud Talk auch für Jitsi Meet und Matrix verwendend werden könnte. Hättest Du dazu eine Idee?
Hi Adrian,
das wird nicht so ohne weitere möglich sein. nginx wirkt hier als Proxy für HTTP(S). coturn nutzt allerdings TCP/UDP. TCP/UDP liegen in der Transportschicht, nginx arbeitet aber auf der Anwendungsschicht.
Man kann hier über ALPN etwas tricksen, wie z.B. bei Jitsi Meet (siehe Beispiel-Konfiguration für nginx). Jedoch wird das Verfahren nicht empfohlen und es macht die generelle Konfiguration von nginx eher umständlich.
Daher würde ich auch empfehlen, die Pakete für den coturn nicht über nginx zu routen.
Gruß,
Jan
Hallo, super Anleitung! Vielen Dank.
Ich habe Nextcloud und letsencrpyt in docker container laufen.
Wahrscheinlich würde dies dann nicht einfach so funktionieren.
Hat jemand nen Tipp wo ich mich dazu schlau machen könnte?
Grüße,
Florian
Hi Florian,
für coturn gibt es ebenfalls Docker-Container (z.B. hier). Da es im Prinzip egal ist, wo coturn letzten Endes läuft, sollte dies ebenfalls funktionieren.
Gruß,
Jan
Hi Jan,
.. da hätte ich doch nochmal eine kleine Frage:
Ich habe das ganze auf dem Rapi 4 laufen und
– Nextcloud, letsencrypt, mariadb jeweils in eigenen docker containern im selben Stack untergebracht. Ausserdem laufen diese auf einer SSD-Festplatte
Coturn läuft nun ausserhalb der Container und funktioniert mit Nextcloud zusammen.
Nun habe ich in der turnserver.conf auch die Verweise auf die cert und pkey hinzugefügt und aktiviert (die Pfade sind ellenlang, da sie auf der SSD-Festplatte liegen).
cipher-list habe ich auskommentiert gelassen, da ich unter nginx auf meinem system den Wert nicht finde.
dh-file habe ich ebenfalls auskommentiert gelassen.
–> coturn läuft und spielt mit nextcloud zusammen.
Ist das so ok und talk ist nun praktisch ssl-zertifiziert, oder habe ich hier noch einen Denkfehler?
Entschuldige die Belästigung mit solchen Anfängerfragen, und ich bin Dir für eine kurze Antwort sehr dankbar.
Gruß,
Florian
Hi,
leider merkt man nicht sofort, wenn der coturn nicht richtig funktioniert. Ich teste das immer von außerhalb über folgende Website: TrickleICE
Hier als „STUN or TURN URI“ einfach ’stun:meinedomain.de:5349′ eingeben (halt noch Domain und ggf. Port anpassen). Bei „Gather candidates“ muss dann mindestens ein „srflx“ Paket dabei sein. Dann ist coturn korrekt installiert und funktioniert.
chiper-list und dh-file kann man noch für maximale Sicherheit in der coturn-Konfiguration hinzufügen.
Gruß,
Jan
Hi Jan,
super, danke für die Erklärung. Habs getestet, es wird ein component type rtp srflx zurück geliefert. Mit meiner IP. scheint i.o. zu sein.
Danke nochmal!
Hi Jan,
Vielen Dank für die schnelle RM! Ja, das werde ich mit nochmal ansehen. Ist gar nicht so einfach, ich habe da aufgrund meiner beschränkten Fähigkeiten ein paar Probleme (ich denke hauptsächlich permissions). Habe Coturn dank Deiner tollen Anleitung nun direkt auf dem Raspi OS laufen. Die Kommunikation mit dem Nextcloud container klappt einwandfrei. Nun werde ich nun noch die exisiterenden SSL cerificates einbinden.. Meine Pfade dazu pass ich auf mein System an.
Grüße,
Florian
Servus Jan,
auch hier noch ein Dankeschön für diese ausführliche Anleitung.
Noch zwei Fragen hätte ich dazu:
1. Gemäß deiner aktuellen Anleitung für Nextcloud unter Ubuntu 20.04
wurden ECDSA und RSA Zertifikate generiert. Auf welche ist in der
turnserver.conf zu verweisen?
2. In einigen Kommentaren wird erwähnt, dass der Coturn Server
bei falscher Einrichtung, z.B. falsche Ortsangabe der Zertifikate, auf eine
unverschlüsselte Fallback-Verbindung zurückgreift. Nutzt der Server
diese unverschlüsselte Verbindung ebenfalls auf dem gewählten tls-port oder wechselt er auf den standard-port? Sollte der Server nähmlich
zum standard-port wechseln, wäre eine Verbindung zum Server aufgrund
der Firewall UFW doch nicht möglich und eine kleine Sicherheit nicht
ungewollt eine unverschlüsselte über den standard-port aufzubauen.
Danke vorab und viele Grüße.
Hi,
1. Bei coturn kannst du nur ein Zeritikat hinterlegen. Hierbei ist es aber egal, ob du das RSA- oder ECDSA-Zertifikat nutzt.
2. Hier findet ein Fallback auf den Standard-Poprt statt. Tipp: Nach Einbindung der Zertifikate und Neustart von coturn mal in die Logs schauen (syslog). Hier dann die Meldungen beim Neustart von coturn durchgehen. Wenn hier irgend etwas davon steht, dass er Zertifikate nicht finden kann, dann hat irgend etwas nicht geklappt.
Gruß,
Jan
Hallo Jan,
meien Cloud ist auf einen Proxmox Server ungezogen und hat nun einen Nginx Proxy Manager der auch die Lets Encrypt Zertifikate erstellt. Wie muss ich das in der turnserver.conf eintragen. Mit deiner Anleitung hat es ohne Proxy wunderbar geklappt
Hat sich erledigt, wein Fehler in der Konfiguration
Hallo Jan,
vielen Dank für das tolle Tutorial!
Ein Hinweis, den ich in den Kommentaren entdeckt habe, sollte auch in der Anleitung direkt erwähnt werden: Die Optimierung von PHP-fpm.
Wie auch in der offiziellen Nextcloud-Dokumentation erwähnt( https://docs.nextcloud.com/server/21/admin_manual/installation/server_tuning.html?highlight=memory%20limit#tune-php-fpm), habe ich die folgenden Werte in der Konfiguration angepasst:
pm = dynamic
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18
Dadurch wird die Reaktionsgeschwindigkeit von Talk (und auch Nextcloud allgemein) deutlich erhöht, der Rufaufbau verkürzt sich enorm.
Da das ganze auch ohne diese Optimierung relativ gut läuft, wird es vermutlich nur wenig Leute stören. Aber ich finde für den geringen Aufwand der Anpassung hat man einen sehr großen Nutzen.
Für mich war das ein „Aha-Moment“, da ich mich schon länger gewundert habe, wieso Talk denn so lange Ladezeiten hat, obwohl der Server an sich weit entfernt von einer Vollast war.
Gruß Clemi
Hi Clemi,
ja, hier kann man durchaus optimieren. Dennoch sollte man die Werte nicht fix auf die vorgeschlagenen Werte setzen (das ist in der NC-Doku etwas knapp beschrieben). Zunächst einmal kann man mit folgendem Befehl herausfinden, ob die Werte überhaupt erhöht werden müssen:
grep max_children /var/log/php?.?-fpm.log.1 /var/log/php?.?-fpm.logpm.max_children kann man berechnen: Speicherplatz, der vom Webserver belegt werden kann/Speicherverbrauch pro PHP-Prozess.
pm.start_servers und pm.max_spare_servers: Anzahl CPU-Cores x 4
pm.min_spare_servers: Anzahl CPU-Cores x 2
Im Netz finden sich aber unzählige andere Strategien, diese Werte zu berechnen. Da dies auch immer etwas individuell ist, tue ich mich da schwer, allgemein gültige Werte in den Blog aufzunehmen.
Vielleicht kann ich dazu aber mal einen separaten Artikel verfassen…
Gruß,
Jan
Hallo Jan,
Vielen Dank für die Anleitung. Ich habe einen neuen Server aufgesetzt nach deiner aktuellen Nextcloud unter Ubuntu 20.04 Anleitung. Danach hatte ich das Problem, dass die key.pem Datei nicht für den turnserver-User lesbar war. die Datei war (sowohl ecc als auch rsa) nur 600 (also rw für den letsencryptuser) musste das auf eine 644 ändern und mich dann (bzw. zuvor) durch die veränderten Pfade der Keys und dhparam files wuseln.
Vielleicht könntest du für zukünftige Leser die Pfade oben auf die der aktuellen Anleitung entsprechenden aktualisieren.
Gruß,
Steve
Hi Steve,
hier ist aber nur die jeweilige key.pem betroffen, oder? Ich werde den Artikel wohl mal etwas überarbeiten.
Danke für den Hinweis!
Gruß,
Jan
Hello Dear Jan
Thank you for your guides, I tried setting up Coturn server by your guides, before everything used to work fine, and now I am getting error „cannot find certificate file“ and cannot start old connection at the turn server logs, I gave the permission chmod 644 as stated in the guide,
Thank you for your guides and Help
Gilad
Hello,
when the error message persists, please check if the certificates are really located in the files specified in the coturn configuration (e.g. use „cat“ in order to check).
Best regards,
Jan
Thank you for your prompt response
I am an amateur
This is from the log file,
Aug 4 02:40:42 chat turnserver: 0: WARNING: cannot find certificate file: /etc/letsencrypt/rsa-certs/fullchain.pem (1)
Aug 4 02:40:42 chat turnserver: 0: WARNING: cannot start TLS and DTLS listeners because certificate file is not set properly
Aug 4 02:40:42 chat turnserver: 0: WARNING: cannot find private key file: /etc/letsencrypt/rsa-certs/privkey.pem (1)
Aug 4 02:40:42 chat turnserver: 0: WARNING: cannot start TLS and DTLS listeners because private key file is not set properly
before it was working find after I did chmod 644 and now no, this is the location of the certification,
Again thank you
Hi,
just try the following:
cat/etc/letsencrypt/rsa-certs/fullchain.pem/etc/letsencrypt/rsa-certs/privkey.pemIf there’s an error message that the file(s) cannot be found, the files are saved somewhere else on the disk.
Also check your coturn config, because there’s a “ (1)“ behind the file names in the log. That looks a bit strange.
Most important ist, that coturn can find the certificate files in the place where it is configured in the config.
Best regards,
Jan
Thank you For taking the time Jan, and I do apologize for bothering you,
I had the same issue for a long long time until I found your guide and when I did CHMOD 644 and then finally it was working, and then suddenly It stop,
I ran the „Cat“ command and the files are there, it shows the output of the files
the config is exactly like you suggesting in the guide
Again thank you!
Hi,
can you try to set the permissions to „777“ (only as a test). This way we can check if the problem is the permission or if we have some other kind of problem.
Best regards,
Jan
Dear Jan
Thank you for taking the time to help me, and I am sorry for my late replay,
I tried to do a fresh install, changed „chmod 777“ and still the same issue
I followed the exact steps by the guide and verified with cat command
Thank you
Hi,
the error messages are still the same?
Best regards,
Jan
Hello
yes it is the same warning messages, when I am trying service coturn service
it shows the service is running
but still cannot gather ICE candidates,
Hi,
I think if it says that it cannot find the cert files, then the files are not present or have the wrong set of permissions. I’ve never seen this kind of problem when it was not caused by one of these two problems.
Best regards,
Jan
Hallo,
vielen Dank für die Anleitung.
Macht es Sinn coturn mit fail2ban abzusichern? Wie würde eine entsprechende Config dazu aussehen?
VG Joe
Hi Joe,
fail2ban ist hier nicht sinnvoll bzw. nicht umsetzbar. Abgesichert ist coturn durch das Secret, welches in der Konfiguration gesetzt wird. Dieses Secret muss ja auch in den nutzenden Services (z.B. NC Talk) hinterlegt werden, sonst werden Anfragen am coturn zurück gewiesen.
Gruß,
Jan
Hallo Jan,
vielen Dank für deine tolle und gut umsetzbare Tuturial-Webseite. Habe hier einiges entnehmen können! :-)
Das Paket coturn ist übrigens nicht mehr oder temprär nicht in Ubuntu 22.04 enthalten…. :-(
Liebe Grüße
Jo
Hi Jo,
danke für den Hinweis. Hier sollten Sie dringend nachbessern, da coturn doch schon eine ziemlich wichtige Komponente ist, nicht nur für NC Talk, sondern auch für BBB, Jitsi, etc.
Gruß,
Jan
Hallo zusammen,
ich habe eine Frage zu Coturn mit einer Dynamischen IP die alle 24 Stunden wechselt. Im Internet findet mal zu hauf die Problematik warum wird hier nciht darauf eingegangen? Wie wird die „external-ip“ behandelt?
Hi,
hier kann „external-ip“ eigentlich nicht gesetzt werden (und wenn nur dynamisch per Scripting, etc.). „external-ip“ wird aber in vielen Fällen gar nicht benötigt, von daher würde ich es mal ohne diesen Parameter testen.
Davon abgesehen ist der Betrieb eines coturn hinter einer dynamisch wechselnden IP nicht die beste Lösung. Besser ist hier ein Server, der eine feste IP hat.
Gruß,
Jan