Jicofo Error after upgrading Jitsi-Meet

Install & Config
#1

After upgrading Jitisi-Meet to the latest unstable branch, it is not working anymore (used to work smoothly before). Upgraded Debian package versions:
unstable/ jitsi-meet 2.0.5330-1 [2,864 B]
unstable/ jicofo 1.0-684-1 [38.7 MB]
unstable/ jitsi-meet-web 1.0.4580-1 [7,639 kB]
unstable/ jitsi-meet-web-config 1.0.4580-1 [16.4 kB]
unstable/ jitsi-meet-prosody 1.0.4580-1 [40.3 kB]

When I try to start a VC, it gets stuck in an endless reconnect (unfortunately something went wrong, we will try to fix this, reconnecting in x secs).

It seems jicofo is not able to start anymore and I see the following log entry:

Jicofo 2020-12-11 12:04:51.723 INFO: [1] org.jitsi.jicofo.JicofoServices.log() Starting HTTP server with config: org.jitsi.rest.JettyBundleActivatorConfig@793be5ca.
Jicofo 2020-12-11 12:04:51.757 SEVERE: [1] org.jitsi.jicofo.Main.log() An uncaught exception occurred in thread=Thread[main,5,main]
java.lang.ClassCastException: class org.jitsi.jicofo.auth.XMPPDomainAuthAuthority cannot be cast to class org.jitsi.jicofo.auth.ShibbolethAuthAuthority (org.jitsi.jicofo.auth.XMPPDomainAuthAuthority and org.jitsi.jicofo.auth.ShibbolethAuthAuthority are in unnamed module of loader ‘app’)
at org.jitsi.jicofo.rest.Application.(Application.java:51)
at org.jitsi.jicofo.JicofoServices.(JicofoServices.kt:85)
at org.jitsi.jicofo.Main.main(Main.java:90)

The prosody server then loops:

Dec 11 12:12:00 mod_bosh info New BOSH session, assigned it sid ‘e8325309-08c1-411e-87bf-c5407ffbb4ba’
Dec 11 12:12:00 boshe8325309-08c1-411e-87bf-c5407ffbb4ba info Authenticated as wbxgzp-u9-g5cfqg@guest.
Dec 11 12:12:01 focus.:component warn Component not connected, bouncing error for:

Please help - cannot find anything unusual.

Thanks
Ravi

Issue with secure domain function of newly installed JM (stable and nightly)
#2

It seems that there is some fixing ongoing as some packages were upgraded in the unstable branch in the meantime. But it was still not working.

As a workaround I manually downgraded from unstable to stable - now it is working again with the same configuration - but of course the old UI.

#3

Confirm 1.0-684-1 in apt unstable is broken reverted jicofo to 1.0-646-1

1 Like
#4

yeah, that’s true. @bgrozev, your last fix included the removal of several instances of tests like
if (authAuthority instanceof ShibbolethAuthAuthority)

could these changes have a relation to

Jicofo 2020-12-14 23:24:16.155 SEVERE: [1] org.jitsi.jicofo.Main.log() An uncaught exception occurred in thread=Thread[main,5,main]
java.lang.ClassCastException: class org.jitsi.jicofo.auth.XMPPDomainAuthAuthority cannot be cast to class org.jitsi.jicofo.auth.ShibbolethAuthAuthority (org.jitsi.jicofo.auth.XMPPDomainAuthAuthority and org.jitsi.jicofo.auth.ShibbolethAuthAuthority are in unnamed module of loader 'app')
        at org.jitsi.jicofo.rest.Application.<init>(Application.java:51)
        at org.jitsi.jicofo.JicofoServices.<init>(JicofoServices.kt:85)
        at org.jitsi.jicofo.Main.main(Main.java:90)
#5

@gpatel-fr I just did a quick test and I don’t see a problem or such exception. Are you running straight from debian packages or you have some modifications?

What I did I create a new DO VM using latest stable, just default settings and then after Let’s encrypt was setup and I tested 3way call I changed the apt line from stable to unstable and did apt update && apt upgrade and then checked jicofo log after it had updated and restarted and tested 3way call again.

I don’t see any problem with jicofo 684.

Hum, are you running with secure domain setup? I will try that now.

#6

problem is with unstable as stated in @Floris’s post. Huh, did not read your full post, sorry.
I have an unstable setup secure domain yes, pretty vanilla, upgraded it from jitsi-meet 2.0.5296-1 to 2.0.5342-1 and then bang nothing works.
It’s an Ubuntu 20.04 container.

#7

Opa, reproduced it @Boris_Grozev

Jicofo 2020-12-16 14:22:25.541 SEVERE: [1] org.jitsi.jicofo.Main.log() An uncaught exception occurred in thread=Thread[main,5,main]
java.lang.ClassCastException: class org.jitsi.jicofo.auth.XMPPDomainAuthAuthority cannot be cast to class org.jitsi.jicofo.auth.ShibbolethAuthAuthority (org.jitsi.jicofo.auth.XMPPDomainAuthAuthority and org.jitsi.jicofo.auth.ShibbolethAuthAuthority are in unnamed module of loader 'app')
	at org.jitsi.jicofo.rest.Application.<init>(Application.java:51)
	at org.jitsi.jicofo.JicofoServices.<init>(JicofoServices.kt:85)
	at org.jitsi.jicofo.Main.main(Main.java:90)
#8

out of curiosity, is there a link with secure domain ? I have trouble understanding that.

#9

And a fix is coming: https://github.com/jitsi/jicofo/pull/655

Here is the link: https://jitsi.github.io/handbook/docs/devops-guide/secure-domain

#10

Gah, of course if you test with anonymous domain the cast is never touched.

#11

Fixed.

#12

Yes, well, Jicofo starts. Videobridge does not work but I have yet to understand what is happening, there may be something specific to my setup.

#13

Coming back to this, yes there was something specific indeed.
I had blocked port 10000 on my workstation and forgotten all about it. And now when Jitsi-meet videobridge can’t connect, the infamous meseage ‘Unforturnately something went wrong’ is no more displayed, everything seems to connect but media data don’t pass and video stay black.
Once this dawned on me getting back functionality on my test server was easy.
Now another problem, why my coturn setup was not working ? it turns (!) out that there has been a slight change in jitsi-meet that means that now the turncredentials module has to be present in the authenticated prosody realm when using secure domain. Only 2 weeks ago having it in the anonymous domain was quite enough, but no more. Oh well, that’s the price of progress probably.