Docker-jitsi-meet: new image fails connecting after upgrading

[brunoamaral]

I am using the docker-compose.yaml file in the repo, and right now jitsi fails to connect after I upgraded the image with docker-compose pull

From the console, I am getting a few warnings but no error:

prosody_1  | focus.meet.jitsi:component                warn Component not connected, bouncing error for: <iq to='focus.meet.jitsi' id='edb00480-10ad-4d5a-9470-2067777e2432:sendIQ' type='set' from='[email protected]/4zHvm8Bw'>
web_1      | 172.19.0.1 - - [07/Apr/2020:21:09:35 +0100] "POST /http-bind?room=testing HTTP/1.1" 200 2962 "https://host.domain.tld/testing" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
prosody_1  | focus.meet.jitsi:component                warn Component not connected, bouncing error for: <iq to='focus.meet.jitsi' id='11fad196-de08-4d79-b87b-9760c34e666c:sendIQ' type='set' from='[email protected]/4zHvm8Bw'>
web_1      | 172.19.0.1 - - [07/Apr/2020:21:09:36 +0100] "POST /http-bind?room=testing HTTP/1.1" 200 478 "https://host.domain.tld/testing" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
prosody_1  | focus.meet.jitsi:component                warn Component not connected, bouncing error for: <iq to='focus.meet.jitsi' id='1a602011-10d6-4412-9b1f-e3e89b806a5b:sendIQ' type='set' from='[email protected]/4zHvm8Bw'>
web_1      | 172.19.0.1 - - [07/Apr/2020:21:09:38 +0100] "POST /http-bind?room=testing HTTP/1.1" 200 478 "https://host.domain.tld/testing" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
prosody_1  | focus.meet.jitsi:component                warn Component not connected, bouncing error for: <iq to='focus.meet.jitsi' id='1a602011-10d6-4412-9b1f-e3e89b806a5b:sendIQ' type='set' from='[email protected]/4zHvm8Bw'>

[brooqs]

Hi,

I had the same situation, so far I have found 2 errors. The first one was http-bind wrong, I fixed this. Then it wrote component-secret no-value in the prosody/conf.d/jitsi-meet.cfg.lua file. When I replaced this with the secret in the .env file it has been working right now. I Hope this help.

Stay Healty.

[porjo]

I can confirm same issue. jifcofo and jvb containers crash soon after starting:

# docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                          PORTS                                      NAMES
e0bd97847ef8        jitsi/jicofo        "/init"             About a minute ago   Exited (1) About a minute ago                                              docker-jitsi-meet_jicofo_1
61669dc467d0        jitsi/jvb           "/init"             About a minute ago   Exited (1) About a minute ago                                              docker-jitsi-meet_jvb_1
1449799842ce        jitsi/web           "/init"             About a minute ago   Up About a minute               0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   docker-jitsi-meet_web_1
7f6831b85040        jitsi/prosody       "/init"             About a minute ago   Up About a minute               5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp     docker-jitsi-meet_prosody_1

[brooqs]

Currently only p2p is running on my server. When the 3rd person enters the meeting, all communication is interrupted. When the third person leaves the meeting, everything returns to normal.

[teutat3s]

might be this commit https://github.com/jitsi/docker-jitsi-meet/commit/5e6faced4ff7724b65d608f6fe93fabe70743efd

[immanuelfodor]

I also removed the public url config to fix the http bind error but I still get a focus unauthorized error. The secret is written to the lua config right, though.

jicofo_1   | Jicofo 2020-04-08 06:27:36.360 SEVERE: [52] org.jitsi.jicofo.JvbDoctor.log() Unexpected error returned by the bridge: [email protected]/YUNYe7LS, err: <iq to='[email protected]/focus85943495815418' from='[email protected]/YUNYe7LS' id='D3lzk-163' type='error'><error type='auth'><not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></iq>

Maybe it's related?

[immanuelfodor]

I've found this line, it doesn't look good:

cat .jitsi-config/jvb/sip-communicator.properties
org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=<no value>@auth.meet.jitsi/.*

What should be at the no value?

[immanuelfodor]

I replaced the <no value> with focus as best guess, restarted the docker compose, and now it works.

[ahoeg]

I tried to install my second test instance with some days delay and also run into problems.

It looks like security was improved in the last days. jicofo container fails with the following error message with the same ENV file and newer images automatically pulled during deploy the containers.

[email protected]    | FATAL ERROR: Jicofo auth password must be changed, check the README

See changed .env file

# Security
#
# Set these to strong passwords to avoid intruders from impersonating a service account
# The service(s) won't start unless these are specified
# Running ./gen-passwords.sh will update .env with strong passwords
# You may skip the Jigasi and Jibri passwords if you are not using those
# DO NOT reuse passwords
#

# XMPP component password for Jicofo
JICOFO_COMPONENT_SECRET=

# XMPP password for Jicofo client connections
JICOFO_AUTH_PASSWORD=

# XMPP password for JVB client connections
JVB_AUTH_PASSWORD=

# XMPP password for Jigasi MUC client connections
JIGASI_XMPP_PASSWORD=

# XMPP recorder password for Jibri client connections
JIBRI_RECORDER_PASSWORD=

# XMPP password for Jibri client connections
JIBRI_XMPP_PASSWORD=

I tried new images (auto pull) with my old ENV file and it fails to. So it looks like simple passwords reject and need to be set secure to start the containers / jitsi service?

[ahoeg]

With the new images I have still errors in the container logs and old images not work with the new env file. So I rolled back my deployed instance ti image tags 4101-2.

[alexruf]

I had the same issue. Problem is the outdated .env config. When generating a new one ensure to run ./gen-passwords.sh before.

[gerroon]

I have the exact same problem. I had perfectly working docker container for over a year with Apache reverse proxy.

I started a totally new git pull with a fresh. I generated the passwords, made sure I have the correct ports, IP, disabled ssl, etc I created an initial Prosody user. I still get the exact same problem.

https://URL/http-bind

It works! Now point your BOSH client to this URL to connect to Prosody.

For more information see Prosody: Setting up BOSH.

So that is not the issue

What is the solution?

[gerroon]

I had the same situation, so far I have found 2 errors. The first one was http-bind wrong, I fixed this. Then it wrote component-secret no-value in the prosody/conf.d/jitsi-meet.cfg.lua file. When I replaced this with the secret in the .env file it has been working right now. I Hope this help.

Stay Healty.

How did you fix the http-bind error? I have aworking http-bind as far as I can tell.

The password is set properly in the file you mention. It still does not work.

[gerroon]

"/usr/share/jitsi-meet/"https:/DOMAIN"/http-bind" failed (2: No such file or directory), client: 172.22.0.1, server

maybe it is a single slash problem?

[Zakspeed]

Currently only p2p is running on my server. When the 3rd person enters the meeting, all communication is interrupted. When the third person leaves the meeting, everything returns to normal.

Duplicate of #403

[chadwallacehart]

I had the same issues. I ended up doing the following:

git pull
cp env. backup.env
cp env.example .env
nano .env
rm -r ~/.jitsi-meet-cfg/jicofo/
rm -r ~/.jitsi-meet-cfg/transcripts/
rm -r ~/.jitsi-meet-cfg/jvb/
rm -r ~/.jitsi-meet-cfg/prosody/
./gen-passwords.sh 
docker-compose up -d

I had to rebuild the .env file and set the passwords. The only configs I cared about were in ~/.jitsi-meet-cfg/web/, so I deleted the others so they would be regenerated. It looked like the autogenerated password was not making its way into ~/.jitsi-meet-cfg/jvb/sip-communicator.properties for some reason.

[gerroon]

@ chadwallacehart

Those are the exact steps I used and it does not work for me.

The only non standard thing I did was to modify couple ports in .env since those ports are already used by my system.

Also the jvb password was set properly for me

I documented my case in this bug

https://github.com/jitsi/docker-jitsi-meet/issues/413

[dedors]

I also had
FATAL ERROR: Jicofo auth password must be changed, check the README

the commands of @chadwallacehart helped. the "git pull" is really important, otherwise the env.example is not updated.

[ahoeg]

With the new images I have still errors in the container logs and old images not work with the new env file. So I rolled back my deployed instance ti image tags 4101-2.

I tested with the new env file too. It doesn't work for me...

[antonanders]

We've had the same issue after upgrading this morning.

seems that the http-bind issue comes from the char " at the beginning of a configured url.
In our case we had to modifiy .jitsi-meet-cfg/web/config.js

        // bosh: '"https://meet.droidnet.de/http-bind', <--- this is wrong!
        bosh: 'https://meet.droidnet.de/http-bind',

and the same for etherpad:

    // etherpad_base: '"https://meet.droidnet.de/etherpad/p/', <-- this is wrong!
    etherpad_base: 'https://meet.droidnet.de/etherpad/p/',

the FATAL ERROR @dedors reported, is simply resolved by adding the new security settings from env.example (see top of the file) to your .env file and running ./gen-passwords.sh (see https://github.com/jitsi/docker-jitsi-meet/issues/404#issuecomment-610756545 )
You need to make sure that you first remove/move your .jitsi-meet-cfg/ folder as to my knowlegte it needs to be regenerated.

[brunoamaral]

For anyone upgrading, I can confirm that changing the .env file to the new version and running gen-passwords.sh fixes the problem. You will also need to delete .jitsi-meet-cfg or whatever your config directory is.

[gerroon]

@antonanders

Your solution definetely takes care of the http-bind issue, so this is clearly a bug, since none of us creates those urls manually.

I can now join the room but I cant see my camera feed, nor I can enbable the microphone or the camera even though the browser has permissions to do so, I get the error below

2020/04/09 09:03:20 [error] 241#241: *11 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 172.23.0.1, server: _, request: "POST /http-bind?room=problematicspinsarriveeast HTTP/1.1", upstream: "http://172.23.0.3:5280/http-bind?room=problematicspinsarriveeast", host: "DOMAIN", referrer: "https://DOMAIN/ProblematicSpinsArriveEast"
web_1      | 172.23.0.1 - - [09/Apr/2020:09:03:20 -0500] "POST /http-bind?room=problematicspinsarriveeast HTTP/1.1" 504 597 "https://DOMAIN/ProblematicSpinsArriveEast" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Safari/537.36"

[freechelmi]

This why the docker-compose need a tag env param for all docker images.

[freechelmi]

For now I went back to git tag stable-4101-1 and used the tag 4101-1 for each of the 4 docker images.

This is 15 days old but it works.

[yosoyfunes]

it work for me

# down containers
docker-compose down

# reset config to tag stable-4101-1
git checkout stable-4101-1

# delete data
rm -r ~/.jitsi-meet-cfg/jicofo/
rm -r ~/.jitsi-meet-cfg/transcripts/
rm -r ~/.jitsi-meet-cfg/jvb/
rm -r ~/.jitsi-meet-cfg/prosody/

# backup environment
cp .env backup.env

# create new environment from tag stable-4101-1
cp env.example .env

# configure .env again
vim .env

# build images to tag stable-4101-1
make all

# start services 
docker-compose up -d

:)

[freechelmi]

I guess most people won't do the "make all" step and just pull the latest images from docker hub , which would IMO not work

[carchrae]

instead of rebuilding, you can just change docker-compose.yml.

change all 4 lines that refer to image, eg

image: jitsi/web

to

image: jitsi/web:4101-1

(you probably still want/need to checkout the env.example for the git version you want, but this saves the lengthy build step. )

changes here

https://github.com/carchrae/docker-jitsi-meet/commit/ef1edaf2c8a79ee564094b6acb6fe62646c9edbb

[EliterScripts]

build images to tag stable-4101-1

make all

I am very concerned, because I just wanted to contain Jitsi within Docker, now it's doing all sorts of sketchy stuff.

[dg-otrs]

We've had the same issue after upgrading this morning.

seems that the http-bind issue comes from the char " at the beginning of a configured url.
In our case we had to modifiy .jitsi-meet-cfg/web/config.js

        // bosh: '"https://meet.droidnet.de/http-bind', <--- this is wrong!
        bosh: 'https://meet.droidnet.de/http-bind',

and the same for etherpad:

    // etherpad_base: '"https://meet.droidnet.de/etherpad/p/', <-- this is wrong!
    etherpad_base: 'https://meet.droidnet.de/etherpad/p/',

the FATAL ERROR @dedors reported, is simply resolved by adding the new security settings from env.example (see top of the file) to your .env file and running ./gen-passwords.sh (see #404 (comment) )
You need to make sure that you first remove/move your .jitsi-meet-cfg/ folder as to my knowlegte it needs to be regenerated.

Make sure not to set the PUBLIC_URL within " " this will lead into the issue.

Just PUBLIC_URL=meet.xxx.com and you are fine without the http-bind issue. Just solved it in my local instance.

DD

[saghul]

Hey all, apologies for the trouble with the update.

This was mostly caused by the fix we made to fix a security problem: https://github.com/jitsi/docker-jitsi-meet/blob/master/CHANGELOG.md#stable-4384-1

In order to fix it I intentionally broke installations on upgrade, so one would not be able to run an insecure installation. It's harsh, yes, but needed.

Wiping the config volume and starting from scratch with a fresh .env file off env.example should yield a working setup. If it ddoesn't, please open a new issue.

I'm closing this one since it has accumulated some noise, with a number of unrelated issues being intertwined.

Apologies.

[EliterScripts]

@saghul yeah, I just looked at it. It is NOT fixed.

[saghul]

Please open a new issue and include all logs.