SSL/TLS error in prosody.log when adding a second videobridge

I’m attempting to set up a second videobridge. Both Jitsi installs are on Ubuntu 18.04 LTS with the main install using the quick install guide and no further customisaiton. I’ve followed this guide to set up the second videobridge. When I review /var/log/prosody/prosody.log on the main install I see the following SSL/TLS errors:

Dec 09 11:21:11 videobridge2.meet-vb2.example.com:tls    error   Error creating context for c2s: No key present in SSL/TLS configuration for videobridge2.meet-vb2.example.com
Dec 09 11:21:11 videobridge2.meet-vb2.example.com:tls    error   Error creating contexts for s2sin: No key present in SSL/TLS configuration for videobridge2.meet-vb2.example.com

I’m unsure if these are of concern? I can not see videobridge2.meet-vb2.example.com:component info External component successfully authenticated in the logs as the guide suggests. Any guidance appreciated.

This is what my prosody.log looks like on the main server, each time I connect multiple users https://gist.github.com/danmaby/b2cf412191f87216558d1654a4e0ea5f

I see the SSL/TLS error then no further reference to the second videobridge on the meet-vb2.example.com domain.

That guide is 5 years old and some of the configs there no longer exist.

It was published in May this year @damencho? I also followed the video guide in the Jitsi Handbook, which I appreciate is 2.5 years old but it followed very closely. Are there any better resources to support the installation of an additional videobridge?

Adding a new bridge on a default jitsi-meet installation that uses https://jitsi.org/qi
is easy, but it is not documented in the official handbook.
After default installation, you need to do few steps.

  1. Get the jvb config and transfer it to the new machine.
  2. Install jvb
  3. use the new configs, and change:
  • the nickname the jvb will use
  • the server-id in the websocket config server-id = jvb2
  • the IP address where jvb to connect to prosody (from localhost to the IP address of where default installation was done) and make sure port 5222 is open and accessible for the second jvb machine
  1. restart jvb
  2. Edit nginx config adding new proxy rule for the jvb websockets for the new bridge. This is the rule for the default bridge https://github.com/jitsi/jitsi-meet/blob/master/doc/debian/jitsi-meet/jitsi-meet.example#L91, just copy it and change the 127.0.0.1 to the address of the new bridge.
1 Like

And if you which when you succeed you can document it in https://github.com/jitsi/handbook by creating a PR. Thank you.

@damencho,

Do you have any suggestion for websocket configuration in an auto-scaling scenario with random IP?

Yep, the way docker made it. The server id is the IP the nginx will use to contact and that is done in the nginx config: https://github.com/jitsi/docker-jitsi-meet/blob/master/web/rootfs/defaults/meet.conf#L40

I’m currently in the process of adding a second jvb to our setup. Could you specify in which config files these settings need to be added/changed, please?

The configuration so far seems to be successful, however on our main Jitsi-Meet installation, we now get the following errors in the prosody log:

Dec 09 22:13:39 c2s55eccf2ced90	info	Client connected
Dec 09 22:13:39 c2s55eccf2ced90	info	Client disconnected: ssl handshake error: sslv3 alert certificate unknown

Thank you @damencho

I have tested today and it’s working, I added a second colibri block after the default one to not break the local JVB and not added the alphabetic chars to the regex since there are only IPs in my case.

    # 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;
    }

    # colibri (JVB) websockets for additional jvb
    location ~ ^/colibri-ws/([0-9.]*)/(.*) {
       proxy_pass http://$1:9090/colibri-ws/$1/$2$is_args$args;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       tcp_nodelay on;
    }