Are there any issues with running Jitsi from Debian 10 (other than that Java thing) so it's better to use Ubuntu? I can't get lobby mode working

And when someone else tried to join, the meeting crashed (at least from the Android app which is at v20.6 which seems to be the latest). I just tried starting a meeting from Firefox on my main PC and it crashed immediately. I have secure domain on. What’s even weirder is that when I enabled TCP 4443 on my router and firewall (because I remember that was one of the ports before the guide was updated) I can enable lobby mode, but I don’t have to log in (so secure domain not working) and when someone else tries joining it still crashes. I update and upgrade the whole system every day I start it for the first time.

I have many Jitsi servers on Debian 10 Buster, no issue…

The lobby mode works. I tried the secure domain in my test environment, it works too but I’m not used on a production environment.

I know it’s all most probably mistakes on my end, but boy is it frustrating and the urge to give up is strong. Like it has a mind of its own and just wants to give me a hard time for fun. I’ve spent too much time trying to get this stuff working.

What are the hardware specifications?

number of cores, RAM etc

It’s a Supermicro H12SSL- i /C/CT/NT. CPU: AMD EPYC 7282 16-Core Processor and 31 gb RAM. Not sure which entry in lshw indicates RAM.

Does your Jitsi work with default settings? Without activating the lobby mode…
Try a meeting with 3 participants

Reinstalled everything (including having purged all the configs before with apt autoremove --purge jitsi-meet) and it ‘works’ but I can’t hear (don’t think I could see either) anything from any of my devices. No lobby option, either. Also strange then when I tried setting it up on Ubuntu on a separate HDD (same server), Certbot failed (some network issue). I’m not sure if I have to do Attempted activating secure domain and lobby but can't start meeting - #9 by Freddie even if I’m not trying to use secure domain. Now Certbot worked but exact same problem as Debian. I checked the Ubuntu logs and don’t see anything that looks like a ‘fatal’ failure, just portmanager error Error binding encrypted port for https: No certificate present in SSL/TLS configuration for https port 5281 though I never got any ‘unsecured site’ warnings when I tried.

Any more ideas?

Bumping again.

From my old notes:
vi /etc/jitsi/videobridge/config
JVB_OPTS="–apis=xmpp,rest,"

What does that do?

Add rest-api, as it says. Please include the trailing comma.

so rest, rest-api, or just rest-api? The API field was empty so I just added xmpp, rest, and now Firefox doesn’t even load the meeting I just started on my other computer.

Bump.

Before I run it:

  1. if my domain is domain.tld and not a FQDN like meet.domain.tld, should it still work?
  2. wouldn’t it be better for every command to run with sudo instead of becoming root (they recommend never using root), especially if root’s disabled on someone’s system?
  3. 2/3 into the script, all the text is highlighted blue. Does that indicate an accidental syntax error is it just an issue on Github’s end?

domain.tld is OK but, it’s needed a second address for TURN too

In my opinion sudo is a bad practice in its commonly used form. But you can change the script as you wish

I’ll check this. Could you open an issue or send me a screen capture for this?

  1. I mean, it’s easy to see but it starts on line 342. And why do you think sudo’s bad practice (and what do you mean by ‘commonly used form’?)

I couldn’t reproduce the same issue but I changed some lines which may cause this type of errors in some situations.

sudo is OK if it is used to allow to run a limited number of commands for some users. But it’s allowed to run all commands in general. So someone who knows the normal account password can run any commands as root.

When sudo is not an option, the bad guy should know the normal account password and additionally the root password to became root.

Maybe it’s not a big problem for a desktop machine whose the security is not so much critical.

I just understood what you mean :slight_smile: GitHub markdown output which can not handle the shell code correctly. This is not a problem