Upgrade Jitsi Meet , problem reservation?

Hi,

I upgraded Jitsi Meet from stable version 5390 to current version 6726.

Now when I start a room I always get an XMPPEvents.AUTHENTICATION_REQUIRED error,
I believe given by a reservation error.

Can you help me understand what has changed since generating this type of anomaly?

I thank anyone who can help me
Marco

Any errors in prosody? Which prosody version is that?

0.11.10-1~bionic1

I did not find any errors on prosody.err.

On prosody.log instead:

Dec 15 15:05:33 c2s558a68929610 info Client connected
Dec 15 15:05:33 c2s558a68929610 info Authenticated as mmy94qwpkuhauyr2@guest.meet-dev.vianova.it

so there doesn’t seem to be anything out of the ordinary …

Did you leave the config files without touching them after the upgrade?

I aligned the config file because I saw it to be a little different (some variables moved etc …).
But basically the same as before …

Hi Damencho,
I’m Marco’s colleague. About the changes done on prosody, we only commented in prosody virtual host configuration the following block:

--Component "focus.meet-dev.example.com"
--    component_secret = "pwd"

and enabled the following:

Component "focus.meet-dev.example.com" "client_proxy"
    target_address = "focus@auth.meet-dev.example.com"

Our Jitsi architecture is based on a Secure Domain setup + external authentication of the owner of the room. About the reservation module we still use the jicofo reservation (in version 6726).

Following our prosody virtual host configuration:
prosody_config_example.txt (6.1 KB)

  1. Do you see any issue about this configuration?
  2. About the jicofo reservation module, even if it is deprecated, does it work properly, if we use them in the last version of jicofo?

Thanks in advance for your support

This should be handled by the postinst scripts when updating.
If the did not get foxed probably you missed and this one which is important jitsi-meet/jitsi-meet-prosody.postinst at 5dee37dd8220888cf587a70bba81c4d9d75fd40c · jitsi/jitsi-meet · GitHub

Sorry,
I forget to attach the command that I used as you suggested:

sudo prosodyctl --config /etc/prosody/prosody.cfg.lua mod_roster_command subscribe focus.meet-dev.example.com focus@auth.meet-dev.example.com

Does the command that I used is correct?
Do I have to follow that one you indicated in the link?

Following jicofo configuration file:
config.txt (1.0 KB)
jicofo.conf.txt (377 Bytes)
sip-communicator.properties.txt (254 Bytes)

following meet-example.com-config.js
meet-dev.example.com-config.js.txt (51.6 KB)

Best Regards
Angelo

What does jicofo log when this happens?
I’m out of ideas … I wonder whether the jicofo reservation plugin is broken again, if that is the case we should just drop it anyway from the code.
Maybe try to use the recommended one

Hi @damencho,
I tested the new prosody plugin for reservation and now the AuthRequired problem is solved.

Thanks again
BR
Angelo

Hi @damencho ,
we noticed that the lua module only works in http. Is https also provided?

Thanks
Marco

It should work with https too. Did you see issues when you configure it with an https api url?

Yes, I set this:

-- local http = require "net.http";
local http = require "ssl.https";

and I have an error at the point

body = http.formencode(request_data);

i had a null error …

The net.http module already supports https. You don’t not need to change the reservation module itself.

It should just work if you configure reservations_api_prefix to point to an HTTPS url.

Inside

async_http_request

, in the cb_ function the response_body is “[unable to resolve service]” … so try again to do warn API Response code 0. Will retry after 3s and then the reservation fails … I have to understand why

Are you able to access your API from the same server using curl?

It will be a lot easier to first debug from outside prosody and first rule out endpoint/accessibility issues before going through the prosody module.

Yes, I did the curl without errors, with 200 ok.

In fact when the reservation was handled by jicofo, it worked.

Perhaps enable debug logging in prosody and see if you can get more details about the failure in prosody log?

From the “unable to resolve service” error I would guess that it is failing at this point – prosody/connect.lua at 068388d9c721b38d6a5643c1cdea9b1d5d9b5494 · bjc/prosody · GitHub – i.e. connection could not be established with your API service.

I enabled debugging and I realized that as DNS it gets a wrong address and not from the host file of the machine …
do you have directions to direct the module to take the dns from the hosts file?

is it not using /etc/hosts at all, or do you want /etc/hosts to take precedence over DNS?

If it is the latter, try changing /etc/nsswitch.conf and make sure under hosts entry files come before dns.