Signaling server behind univetnion

UCS - Univention Corporate Server
,
#1

UPDATE

UPDATE I managed to get a 503 error: I used a different DNS name for a virtual server entry:

<VirtualHost *:443>

ServerName sig*****.com
ProxyPass "/standalone-signaling/" "ws://192.168.1.72:8080/"
ProxyPassReverse "/standalone-signaling/" "ws://192.168.1.72:8080/"

# Enable proxying Websocket requests to the standalone signaling server

RewriteEngine On
# Websocket connections from the clients.
RewriteRule ^/standalone-signaling/spreed$ - [L]
# Backend connections from Nextcloud.
RewriteRule ^/standalone-signaling/api/(.*) http://192.168.1.72:8080/api/$1 [L,P]

Hello there!

Can someon help me setup Nextcloud signaling server behind an univention server. My Univention server would be the public facing webserver. I set up may signaling server hopefully fine.
BUT I can’t figure out the virtualhost on univention.
My config currently is:

<VirtualHost *:443>

    # ... existing configuration ...

    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass "/standalone-signaling/"  "ws://192.168.1.71:8080/"

    RewriteEngine On
    # Websocket connections from the clients.
    RewriteRule ^/standalone-signaling/spreed$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/standalone-signaling/api/(.*) http://192.168.1.71:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>

But I only get an 404 error. (I already enabled the site)

I followed this guide:


and this guide:

Thanks in advance!

#2

Hi @Byter

I come back to this because my signaling server is working now. I’ve followed this guide:

https://markus-blog.de/index.php/2020/11/20/how-to-run-nextcloud-talk-high-performance-backend-with-stun-turnserver-on-ubuntu-with-docker-compose/

which is pretty much the same but as a docker version. So I just run it with the already installed docker on UCS. (And of course the univention-firewall.service)

Both how-tos just reference for the apache-vhost the github suggestion from the signaling server.
But you need an additional slash on the first RewriteRule:

<VirtualHost *:443>

    # ... existing configuration ...

    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass "/standalone-signaling/"  "ws://127.0.0.1:8080/"

    RewriteEngine On
    # Websocket connections from the clients. !!! see the additional slash compared to 
    # strukturag/nextcloud-spreed-signaling on github
    RewriteRule ^/standalone-signaling/spreed/$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/standalone-signaling/api/(.*) http://127.0.0.1:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>

There is in fact already a commit and pull request from february but it didn’t pass until now. https://github.com/strukturag/nextcloud-spreed-signaling/pull/82

I write because on my five hours troubleshooting-way I also thought of dns errors before investigating more into the apache rewrites…

And another thing:
I have the feeling, that the signaling server really improves also connections with just two or three participants. So I can really recommend this peace of software.

Best, Bernd

1 Like
#3

Will try it again soon. I gave up on it last year, but it will be needed again soon, I will give it a try again, thanks!

#4

Hey!
Thanks for sharing! Did you also configured properly the ngnx server for the signaling?
Also I installed this again, it working with the local IP, but if I try it out from the outside Nextcloud gives me an unkown error. To be perfectly honest, I’m really fed up with this. Talk is nearly unusuable right now, I’m hoping that the HPB would solve it. But since I not able to complete the setup for some reason for years now. I’m thinking abandoning the entire thing…

#6

Hey!
So I guess I managed to get the farthest with this:
But it says:

“Failed to establish signaling connection. Something might be wrong in the signaling server configuration”

Is it still possible that my proxy isnt set up properly? Or its great and I screwed up something during the setup? I can curl the signaling service from anywhere!

<VirtualHost *:443>

    # ... existing configuration ...

    ServerName si***.***s.com
    ProxyPreserveHost ON
    ProxyRequests ON

    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass /  "ws://192.168.1.73:8080/"
#    ProxyPassReverse /  "http://192.168.1.73:8080/"

#    RewriteEngine On
    # Websocket connections from the clients. !!! see the additional slash compared to
    # strukturag/nextcloud-spreed-signaling on github
    RewriteRule ^/spreed/$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/api/(.*) http://192.168.1.73:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>
#7

Hey,

it seems like I finally figured it out! So actually the last vonfig for proxying works. The problem was that I’m using a couple of CNAMEs for my nextcloud server. YOU HAVE TO FILL IT OUT IN THE SIGNALING CONFIG WITH YOUR CNAMEs as well. I didn’t figured it out yet how to use it from different CNAME’s at the same time, butI guess that something I can live with. Thanks!

Mastodon