Actually the way to copy cert+key and chown for only the particular user is the most recommended way for security reasons. Only if you have several different services that require access, the shared group solution is handier.
Ah jep, strict permissions are most important for your private key of course, while the certificates are public anyway and by default have weaker permissions .
The service name is coturn, at least on Debian/Raspbian, if you installed via APT, so: systemctl enable coturn
And donât forget: sed -i '/TURNSERVER_ENABLED/c\TURNSERVER_ENABLED=1' /etc/default/coturn
Otherwise the service will immediately stop.
Otherwise it might partly work on other Debian-based distros/systems, but leaves the config left with some wrong estimated variables => coturn settings, based on environment expectations, SSL via LetsEncrypt and others.
Can the TURN server be on the same server as Nextcloud itself? If so, I imagine we cannot refer to the TURN server by the IP address (within Nextcloud configs) as 127.0.0.1.
Both can be on the same machine, but within Nextcloud settings, you still need to set the public/external IP. This is used by the end user WebRTC clients (browser, Android app), not by Nextcloud.
What if we installed our Nextcloud from a snap? That would introduce some complications, I think, to get coturn working on the same server as the snap. I made a post asking deeper questions about this here.
Hi Michalng,
Your efforts on this matter are greatly appreciated! I just wanted to react to one of your quotes here as I think things have shifted in favor of your idea of bundling TURN together with TALK (and STUN).
Recently I have discovered and deployed Yunohost (self hosting solution which lets you install apps - such as NextCloud - in a GUI with the simple click of a button), and have installed NextCloud on it. Both Yunohost and Nextcloud share the mission of making self hosting (a cloud) accessible/maintainable for many many more people. The choice of only using GUIs and making installing apps easy by just clicking an install button are two ways in which this mission is accomplished.
Videocall use cases and low level of technical expertise
I am a user of NextCloud who - probably like most other users - has not deployed it for use by a huge company, but just for home use and perhaps a smaller company. In these use cases it does not make any sense to only use the TALK videocalls within the local network. As most homes or smaller companies just have a kitchen/meeting room and donât need video calls inside the same building. Where NextCloud talk becomes interesting, is when videocalls work with people outside of the local network. Since I suspect that this is the goal of most people who install TALK on NextCloud, it is very inconvenient that they then land into having to do all kinds of expert level terminal work and understanding. Especially when these users are more and more almost non-experts being able to host themselves through the great efforts of projects like NextCloud and Yunohost.
Developer and user effort and losing (potential) users
In connection to the above, I would like to comment on what you said about a bundling solution: âOn the other hand this means always additional effort for maintaining the fork or bundle (depending on how far the integration should go)â. I am not a developer - more of a designer/creative researcher - so I donât know exactly how much time it would take a developer in this case. However, I do know that if these one or a few developers do not take a few hours to do this, then all thousand or more non-expert users have to spend an almost similar amount of time each reading up on the issues and instructions and installing; probably resulting in a much larger cumulative cost in time, a possible source of irritation and in many cases just a switch back to Skype or another platform than NextCloud (for example Google Drive/Talk). That would be ashame of such a good project such as NextCloud and TALK.
An ideal solution
I would really wish that the installation of TALK in NextCloud would enable videocalls outside the local network by default, and that there would be no - or only little GUI - configuration required.
(By the way, in the installation process then it would be helpful to also give instructions about port forwarding for both TCP and UDP, I ran into trouble only having TCP in place first)
How to get there
My question to you (and perhaps others on the forum) is if the above wish could be accomplished and how? (And if it is far too difficult, how could creating an easily configurable TURN server be made available for Yunohost for example?)
Thanks again for you efforts already! I look forward to your answer(s). From a designer and less-expert user perspective I might be helpful in fleshing out a solution.
Other potentially helpful sources
P.s. Some other interesting links about TURN in this context and could perhaps be used for working toward a GUI solution:
Apparently there is a kind of TALK installation script which already configures a TURN server: Script for installing Nextcloud talk with TURN configuration: Setting up firewall for TURN server - #4 by enoch85
As long as the server is on Ubuntu 18.04 the scripts from the VM should work. All it does is checking open ports, installs the needed packages and then adds the needed configuration.
Give it a try. If it doesnât work, please let me know.
However, actually nowadays I think different about the idea to have TURN natively integrated into the Nextcloud Talk app, for the following reasons:
Indeed having the ability to make video calls across the www through local NAT is a feature that many require, but not all. Generally a modular system, that allows to only load/install the required features, is preferable in terms of system resources and compatibility with different application scenarios. There are also situations thinkable where the company is larger and has different international locations, which are for privacy reasons connected via VPN tunnels. There as well direct P2P video calls are possible without a TURN server.
Explicitly privacy is a topic when it comes to a TURN server usage. In a native P2P call, the Nextclouds server machine does not even know about details of the video call. It just handles authentication, but afterwards all data streams are just between the two clients via their WebRTC client (browser, Nextcloud Talk mobile App, or other WebRTC client). If you have a TURN server in between, all data steams go though it, can be logged and theoretically decrypted/read in detail. Of course usually you (should) trust the TURN server owner/machine to respect whatever privacy agreement you accepted, but if one wantâs to be sure, direct P2P is always preferable, as well in terms of performance/resource usage.
Currently coturn is indeed THE standard TURN server on the open source market. At least I couldnât find any other for Linux. But integrating it into the Talk app would weaken possible alternative/new solutions from the start, and, is a decision that can be hardly reverted afterwards, e.g. if a better/modern new TURN implementation arises with promising advantages. So it limits flexibility after all.
On small networks with a low amount of call attendees, having Nextcloud and the TURN server on the same machine works well, but if you need a more reliable setup that as well allows a high amount of users in group video chat, the TURN machine will be quite stressed, perhaps taking important resources from the Nextcloud server/webserver and/or database. As well having both behind the NAT leads to additional resource usage and signal lag. In those cases it is in general recommended to run the TURN server on a dedicated machine, directly attached to the www and not behind the NAT. So in worst case you have two NAT (each client side) instead of four (client1 out > TURN server in > TURN server out > client2 in).
However this has nothing to do with 3rd party distros/solutions to have an integrated installer that does install and setup of Nextcloud + Talk app + TURN server all together.
It can be implemented into Yunohost as well for sure, which seems to have a very similar aim than DietPi (enable simply integrated one-step installers via GUI).
Just note that the installs/configs enable a certain use case, based on the aim of the OS/solution and surely do not fit in all use cases.
Just a final history note about the Talk app:
At start, it was separated into a dedicated WebRTC server and a Nextcloud app: Spreed.ME
You needed to install the dedicated WebRTC server and then configure the app to use it to provide video calls and chat within the Nextcloud interface.
Nowadays both functionalities are merged into the Talk app, which is already a great enhancement in terms of end user comfort. This also makes (more) sense, since the app is never able to do anything without a WebRTC server in the back. But the TURN server indeed is just an additional functionality, only required in some (although perhaps many) scenarios.
About more details how to install and configure coturn with Nextcloud as automated script, I just link the current code we use in DietPi, for reference. In the Nextcloud VM this looks similar, but both depend moreless on the base system, which might be different on Yunohost:
Thanks for describing the procedure. I have successfully followed it on a OpenSUSE host, using the the turnserver package by Bruno Friedmann found in OpenSUSE Buildservice
Actually the way to copy cert+key and chown for only the particular user is the most recommended way for security reasons. Only if you have several different services that require access, the shared group solution is handier.
.
If it doesnât work, please let me know.