Is there a way to revert to Jitsi before 30-03-2020?

Hi,
not criticizing at all the great job done here, I’d just like to revert to previous version which was working like a charm (I’m pretty sure the current version will be working fine soon)

Is there any way to do it?

What is not working? We had identified few things and will push an update.
To fix things, we need first to get them reported. Logs, problems, steps that get you there? Have you done any uninstall?

Hi @damencho,
yes, I have installed from scratch several times. I also have two servers, one with the quick install method, other with the docker method to find which one give best results.

With Quick install method:
By reading this thread I could fix the nginx not restarting issue, by either removing the server part in 60-jitsi-meet.conf or changing the port from 443 to 4444 in the secure part of my.domain.conf
Funny thing is the letsencrypt script seems to do the last action by itself. Though I’d prefer using my own certificates, I used the letsencrypt script in case it fixes also other things.
I had the issue of rooms crashing when someone enters (videobridge issues in javascript console) that seems fixed by following these steps ( passwd jvb@auth.my.domain.com)
And I have the no video issue when a third person enters the room. Mobile app is working, but with the same limitations as web application.

With docker, install works well (I have to use my own certificates, because I used the script too many times and went out of letsencrypt weekly limitations)
As a workaround for the rooms crashing when two people are in the same rooms I had to comment the JVB_STUN_SERVERS line following this post
Unfortunately I face the same no video issue with more than 2 people and the mobile app can’t join the room (only see the spinning pre-loader). I tried to use the images with tag 4101 also but did not see any improvement.

I wanted to revert because while I can use on of the server to make tests and reports logs (it’s it purpose in fact, it’s my testing machine for jitsi), the other one was used in production and upgraded apparently by mistake. This is unfortunately the only server we did not have a snapshot of, and I just needed it to go back to previous working state quickly.

For the logs, sure I can here make the tests and reports you may need with my testing server :slight_smile:

2 Likes

Couldn’t agree more. Only one running server is left and the rest of our jitsi server farm (debian stable) is down since installation of the latest stable release (from scratch, greenfield; no upgrade!).

The docker images with tag 4101 work fine for me on Ubuntu 18.04 (had trouble running these on Debian Buster). You can place an nginx proxy in in front to terminate TLS, forwarding 443 to localhost:8000, and disable https in the .env file. This may make it easier to deal with your certificate issues.

Hi @plokta, does mobile app works correctly also? Sorry to ask that, but can I have your nginx conf (to be sure I don’t forget anything)
Did you have to comment the JVB_STUN_SERVERS line?

I just proxy the root location like this:

        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_pass http://localhost:8000;
                proxy_read_timeout 90;
    
                proxy_intercept_errors on;

                proxy_redirect http://localhost:8000 https://meet.example.com;
        }

I did not need to comment the JVB_STUN_SERVERS line in the .env file and mobile apps work just fine.

1 Like

Well it doesn’t work for me, still needing to comment the line. Maybe because I’m behind a NAT.

One solution is to use the older releases:
The following commands have provided me a running system…

apt-get install jitsi-meet-prosody=1.0.3729-1 jitsi-meet-web=1.0.3729-1 jitsi-meet-web-config=1.0.3729-1 jicofo=1.0-508-1 jitsi-meet=1.0.4101-1
apt-get purge jitsi-meet-turnserver
vi /etc/prosody/prosody.cfg.lua

Note that the editing of the prosody configuration was necessary as major parts have been missing in the installation (This is strange as it came well-configured in my last tries).

systemctl stop nginx
systemctl stop prosody
systemctl stop jicofo
systemctl stop jitsi-videobridge
systemctl stop jitsi-videobridge2
systemctl start nginx
systemctl start prosody
systemctl start jicofo
systemctl start jitsi-videobridge

Enjoy!

2 Likes

Thanks @gs4711
On my side it was really promising until I went on adding several members in room. Now facing again the room crashing when another person enters.

Hi @ashledombos, it seems like we ran into the same issues My post

Just to make sure, you were able to restart NGINX with the new Jitsi version? Where exactly did you do this? Is it 60-jitsi-meet.conf or the default.conf in sites-enabled?

I currently have two site-enabled confs, one for Jitsi and one for Mattermost. Mattermost listens to 443 and has a dedicated host name. Jitsi has the default config for

server {
    listen 4444 ssl http2;

If I change the modules.conf, wont it break something with the sturn server?

Changing modules.conf to port 4444 fails also, just an idea.

Apr 01 11:01:20 communication nginx[13675]: nginx: [emerg] bind() to 0.0.0.0:4444 failed (98: Address already in use)
Apr 01 11:01:20 communication nginx[13675]: nginx: [emerg] bind() to 0.0.0.0:4444 failed (98: Address already in use)
Apr 01 11:01:21 communication nginx[13675]: nginx: [emerg] bind() to 0.0.0.0:4444 failed (98: Address already in use)
Apr 01 11:01:21 communication nginx[13675]: nginx: [emerg] bind() to 0.0.0.0:4444 failed (98: Address already in use)
Apr 01 11:01:22 communication nginx[13675]: nginx: [emerg] bind() to 0.0.0.0:4444 failed (98: Address already in use)
Apr 01 11:01:22 communication nginx[13675]: nginx: [emerg] still could not bind()
Apr 01 11:01:22 communication systemd[1]: nginx.service: Control process exited, code=exited status=1
Apr 01 11:01:22 communication systemd[1]: nginx.service: Failed with result 'exit-code'.
Apr 01 11:01:22 communication systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has failed
-- Defined-By: systemd

Please note, that it works for me, now.

Note, that you’ll have to adapt the prosody configuration file. The default does not work for me.

It seems there has been some updates, now it works (just have to change by hand the port in nginx from 443 to 4444)

Also I did not notice this line which has been added recently in Quick Install guide

And comment the existing org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES.

The only weird behaviour left I have is mobile app not working with company certificates, needing Let’s Encrypt ones…