Nextcloud Talk Signaling Server - now automated installation

root@cloud01:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1       cloud01.MyDomain.net      cloud01
127.0.1.1       talk01.MyDomain.net       talk01

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

OK, thanks!

And both cloud01 and talk01 are the same external IP? Do you run your own DNS server?

Yes, thatĀ“s right
Yes, thatĀ“s right

Aah ok, then that might be the cause. Normally you shouldnā€™t have to add that to the hosts file if you donā€™t specifically need to tell your DNS that itā€™s there. That might also be the reason the error didnā€™t show up in our testing. Because cloud.whatever.com already points to the same external IP as for talk.whatever.com.

Anyway, thanks for confirming. :+1: Iā€™ll think of a fix for this!

Ok, so the right thing is: BOTH entries have to go in?Is that correct?
And I can enter it right before starting the scripts?

Well, then, since test installation, I run it again completely correctly.

Well, only one should be needed, being the cloud entry.

Typically you choose to install Letā€™s Encrypt before you run any apps script, and then the cloud.domain.com is already there, which should be the only one needed.

But if itā€™s working now, thereā€™s no reason to change.

Just for testing sake though, you could try to remove the talk01 and then reinstall and see if it works.

I tried to install it on the same server as Nextcloud but on a subdomain. Talk installed fine, but when installing the signalling server things got wrong as the script tried to install Apache while I already has Nginx in use (using the installation script by c-rieger.de. Is it possible to do something with this webserver conflict? Thanks!

Thanks for posting.

Nginx isnā€™t really optimal to use together with Nextcloud. Hence we chose Apache in the VM.

The script is developed ro run under Apache - and especially with the Nextcloud VM. Sure, you could run both, but Iā€™d actually recommend to run Apache all along.

@enoch85 what are the ā€œspecialā€ settings needed to run the signaling server. maybe itā€™s enough to add this to the nginx config.

that is to say: what is the difference in the apache conf between nextcloud with or without signaling server. what did you add to make the signaling server work?

Awesome work, is it possible to run this on a standalone system/virtual machine that should only run the signalling server?

Thanks, for quick reply. I never heard about that, and the installation scripts that I know use Nginx. Generally Nginx is praised for being less resource intenstive. So if there could be added something to the script to make it work with Nginx would be perfect. I run NC on a VPS, so I never considered your VM. I see you have an option for a VPS as well, maybe I will try that for my next install

Thereā€™s a lot, we basically threw the old Talk script away and made a new one. There are multiple Nginx configs online if you promtly want to run Nginx. Just use your favorite search engine. :wink:

You can read the script, but basically:

  • Apache Proxy
  • TLS to that proxy
  • All the packages needed for it to run
  • CLI commands to prep everything
  • And moreā€¦

Thanks! :smiley:

I never tried it Standalone, but it will check if Nextcloud is installed and all that. Though itā€™s pretty generic code Iā€™d say, so give it a try and report back, Would be interesting to know! Remember to keep backups!

Yup, and thatā€™s true as well. Nginx is very good at serving static files, like webpages and so on. Nextcloud isnā€™t a webpage. :slight_smile: Sure, your GUI will fly, but what about file syncingā€¦?

Iā€™ve seen many bugs regarding Nginx in use with Nextcloud over the years. I spent some time today trying to find a good explanation I stumbled across a few years ago regarding why Nginx is a bad idea for Nextcloud, but my search engine skills failed me this time. :confused:

Anyway, I run Ngix as well, but as a Reverse Proxy for all my servers. Itā€™s really nice!. All and all, I know Nginx, I know Apache. They are good at different things, and I wouldnā€™t suggest running Nginx for Nextcloud.

Youā€™re very welcome to try out the official VM scripts whenever you want. :+1:

Which are the limitations with a regular Nextcloud + Talk + Coturn setup? Or is this relevant for the official VM only?

Iā€™d like to test and probably implement but first want to understand what it is for :wink:.

Maybe this one? https://ownyourbits.com/2017/06/12/why-nextcloudpi-uses-apache-and-not-nginx/ It was posted in this thread, where people were divided between both web servers Why Nginx instead of Apache? but it seems to be easy to switch between the webservers, so that I donā€™t need to re-install everything. My current Nextcloud instance that Iā€™d like to retire has been using Apache without issues, I installed everything manually, so only the new install was a lazy one by using c-riegers script with Nginx Nextcloud 23 (Nextcloud Hub II) Installationsskript - Carsten Rieger IT-Services

1 Like

My understanding is, it revolves around the fact that traffic increases as a square of the number of participants: for N users the number of streams to handle is N*(N-1) - every user (N) sends its audio/video to everyone else (N-1)ā€¦

By introducing a signaling server, every user sends out only one audio/video stream and this server takes care of distributing it to others. It also performs some other duties: codec selection (if available), synchronization, optimization, downconvertion if needed, etc.

STUN and TURN servers solve the issue of users behind routers/firewalls.
To optimize the two-way audio/video traffic for 10+ participants it is not enoughā€¦

3 Likes

Many thanks for this great explanation. Yes that totally makes sense. It basically includes the TURN functionality then, right?

Not necessarily. Different technologies.
But just like TURN servers often do STUN (e.g. coTURN), so signaling might do everythingā€¦

Yeah I mean since it replaces P2P with a server-client model, it works around issues with firewalls and symmetric NAT as well, so no TURN/STUN required anymore. Although in case if two peers only, a direct P2P connection, in case with help of STUN, would be great to avoid unnecessary traffic through the signaling server.

Nope, but close :wink: It was a user on Github, but thereā€™s so many issues to search in. :smiley:

Anyway, Iā€™m also lazy, hence I made the scripts. If you feel like it, try the out like you did with Riegers stuff. Would be great with some feeback!

Spot on! Thanks! :+1:

The difference is what @anon71540698 already pointed out. You can handle more users with a seperate STUN server. But with this fix, you run STUN and TURN on the same server but on different domains. The STUN server is proxied.

But, it still allows for better quality and more users, and youā€™re not limited to the previous TURN limitations by just installing the default TURN server.

I tried Documize on a cheap VPS (LXC, Ubuntu 20) with 1GB RAM and it worked! A highly complex script that does a lot more than any of the others. Letsencrypt did not work, though, it said snap was not fully supported. Right now, record low 200 MB are used! I am impressed. Will explore more, thanks a lot for the scripts!

1 Like