Guide how to limit users with mod_muc_max_occupants.lua

@gpatel-fr thanks for the response and for the clarification around the two locations.

When you say the parameters are set globally, would be mind explaining how? I was under the impression the route I’d taken was a global setting?

Thanks also for the heads up on this. I can see in my latest prosody.log that I’m now receiving focus.meet.example.com:component info External component successfully authenticated with this updated component:

Component "conference.meet.example.com" "muc"
    storage = "none"
    muc_max_occupants = 3
    modules_enabled = {
        "muc_meeting_id";
        "muc_domain_mapper";
        "muc_max_occupants";
        -- "token_verification";
    }
    muc_access_whitelist = { 
        "recorder@meet.example.com";
        "focus@auth.example.com"; 
    }
    admins = { "focus@auth.meet.example.com" }
    muc_room_locking = false
    muc_room_default_public_jids = true

But still able to get more than two users on a call.

like this

muc_max_occupants=2
muc_access_whitelist = { "focus@auth.meeting.myurl.mytld" }

(....)

Component "conference.meeting.myurl.mytld" "muc"
    storage = "memory"
    modules_enabled = {
(...)
        "muc_max_occupants";
(...)

Thanks again, so this is my config in my /etc/prosody/conf.avail/meet.example.com.cfg.lua and this is my latest prosody.log but still no joy with limiting the number of attendees, after restarting prosody and jicofo service.

muc_max_occupants = 3
muc_access_whitelist = { 
        "recorder@meet.example.com";
        "focus@auth.example.com"; 
    }

Component "conference.meet.example.com" "muc"
    storage = "none"
    modules_enabled = {
        "muc_meeting_id";
        "muc_domain_mapper";
        "muc_max_occupants";
        -- "token_verification";
    }
    admins = { "focus@auth.meet.example.com" }
    muc_room_locking = false
    muc_room_default_public_jids = true

hmm… at this point I’d begin to debug the thing.
Can you check if the module is even run ?
goto /usr/share/jitsi-meet/prosody-plugins, save mod_muc_max_occupants.lua

mv mod_muc_max_occupants.lua mod_muc_max_occupants.lua.old
cp mod_muc_max_occupants.lua.old mod_muc_max_occupants.lua

then edit mod_muc_max_occupants.lua to include after
if user == nil then
return
end

something along the lines of

module:log("info", stanza.attr.from);
module:log("info", tostring(whitelist));

restart prosody jicofo and friends and try to enter a meeting with 2 participants, can you see additional lines in prosody.log with your whitelist ? if not, your muc_max_occupants setting is not taken in account.

@gpatel-fr thank you very much for sticking through this to try and help!

I’ve followed your advice but I am still able to bring more than 2 users into a call.

This is my full prosody.log (anchor link starting at the latest test with above changes). The whitelisted user focus@auth.example.com is referenced here in the log.

I’ve just discovered this error in the jicofo.log but not sure if it’s related to this issue?

Jicofo 2020-06-06 19:40:00.936 SEVERE: [17] org.jitsi.impl.protocol.xmpp.OpSetSimpleCapsImpl.log() Failed to discover features for focus.meet.example.com: XMPP error reply received from focus.meet.example.com: XMPPError: service-unavailable - wait

this is NOT the debug line I asked you to add. This is a normal line displayed even if the lua module was not included. So your module is probably not activated at all.

Try this: in the lua module, after the

local MAX_OCCUPANTS = module:get_option_number("muc_max_occupants", -1);

insert the following line:

module:log("info", "max check=%s", tostring(MAX_OCCUPANTS));

and restart prosody. Then you should have in the log the value that the module gets (no need to start a meeting)

Sorry, still trying to work a lot of this out! Thanks for your patients.

This is my prosody.log from immediately after your suggested update. muc_max_occupants appears to return -1 (live 23) if I’m reading this right? Which I’m assuming means unlimited participants?

in a way, yes since the whole module is never run if MAX_OCCUPANTS is <= 0 (see last line). So the problem is with your line configuring muc_max_occupants.
I have it at the beginning of the file like this:

cross_domain_bosh = false;
consider_bosh_secure = true;
muc_max_occupants=2;

can you do the same and check that you don’t have any other line setting this value in the rest of the cfg.lua file ? If there is still no change after that, also check that this file is the one that Prosody actually uses, rename it and see if Prosody don’t start after that - obviously if it does there is a misunderstanding on the config file reference.

I moved muc_max_occupants to the top of the file as suggested. I also removed /etc/prosody/conf.avail/meet.example.com.cfg.lua and tried to restart prosody services, which failed. Added meet.example.com.cfg.lua back and prosody services successfully restarted.

This is my prosody.log following the restart and a test call with 6 participants.

You’ll see line 15 now states muc_max_occupants info max check=3

But I’m still able to bring multiple participants into a call.

it seems that for some reason this needs to be at the top of the file. Oh well.
So the module should have been hooked now yet I don’t see the lines I asked you to add the first time. Are these lines (such as module:log(“info”, tostring(whitelist)); ) still in the module file ?

Edit: you moved the line defining the max occupants at the top of the file, did you move also the line defining the white list ?

Yes, all the lines you’ve shared are still included in mod_muc_max_occupants.lua

Edit: yes, I moved the whitelist line with the muc_max_occupants line.

you did everything perfectly !
after all this I had a sinking feeling and checked again your log, not where I expected the log line, but at the very beginning; you have Prosody 0.10. I have Prosody 0.11.4. I’m afraid that’s a blocker if you can’t upgrade.

I was literally just going down that same route. I’ve just tried How to Upgrade Prosody >0.10.0 for speakerstats to work, Installed using Quick Installation Option but it’s stayed at 0.10 using stable as the version. So digging around now to work out this upgrade.

You need to use prosody official repo in-order to get latest prosody version, follow the below :
https://prosody.im/download/package_repository

Backup your system before the upgrade.

Best Regards,
Mohamed Abada

I’ve upgraded prosody to 0.11.5 but it’s caused a stack of problems. About ready to bin this whole project. So frustrating! I’ve tried the various solutions that have worked for others when upgrading prosody;

  • add Include “conf.d/*.cfg.lua to /etc/prosody/conf.avail/meet.example.com.cfg.lua but that just threw thousands of errors in the logs.
  • change storage = "memory" in /etc/prosody/conf.avail/meet.example.com.cfg.lua.
  • add cross_domain_bosh = false; and consider_bosh_secure = true; to /etc/prosody/conf.avail/meet.example.com.cfg.lua.

Not that any of them have helped, my install is now throwing a dozen 502 errors in the console, with very little actually functioning.

For anyone interested, my workflow for updating prosody from 0.10.0 to 0.11.5 (backup before you start, things will break!):

$ lsb_release -sc
$ wget https://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add -
$ nano /etc/apt/sources.list
$ deb https://packages.prosody.im/debian bionic main
$ sudo apt-get update
$ prosodyctl cert generate meet.example.com auth.meet.example.com
$ sudo systemctl restart prosody.service

Thanks @gpatel-fr and @Mohamed_Abada for trying to assist, appreciate your time.

share your prosody, jicofo and jvb logs @danmaby

Thanks for persisting @Mohamed_Abada, here are the full prosody.log and jvb.log post prosody update.

The jicofo.log was too large for Gist! So I’ve uploaded a redacted version of it here.

I can’t say that I have had cause to regret my stay-current method, that is, use containers to get the ‘best’ flavour used for a particular server project. If I want to use a project using centos, I spin a Centos container. If I want to use a project using Ubuntu, I spin the latest Ubuntu container unless it’ too recent then I spin the previous LTS. Upgrading libraries by hand is a pain, even more to maintain. Learning to use containers is not as hard in the long run.

On a less metaphysical plane, working Prosody is listening on port 5280 and 5347 while your custom upgrade is not, it’s definitely a show stopper.

@danmaby in your prosody logs I can see the following :

> Jun 06 23:06:35 certmanager	error	SSL/TLS: Failed to load '/etc/prosody/certs/localhost.key': Check that the permissions allow Prosody to read this file. (for localhost)
> Jun 06 23:06:35 localhost:tls	error	Error creating context for c2s: error loading private key (Permission denied)
> Jun 06 23:06:35 certmanager	error	SSL/TLS: Failed to load '/etc/prosody/certs/localhost.key': Previous error (see logs), or other system error. (for localhost)
> Jun 06 23:06:35 localhost:tls	error	Error creating contexts for s2sout: error loading private key (system lib)
> Jun 06 23:06:35 certmanager	error	SSL/TLS: Failed to load '/etc/prosody/certs/localhost.key': Previous error (see logs), or other system error. (for localhost)
> Jun 06 23:06:35 localhost:tls	error	Error creating contexts for s2sin: error loading private key (system lib)

To fix the above you need to execute the below :

sudo chown prosody:prosody /etc/prosody/certs/ -R
sudo /etc/init.d/prosody restart
sudo /etc/init.d/jicofo restart
sudo /etc/init.d/jitsi-videobridge2 restart

Most likely this will mitegate the errors and exception you’re getting in Jicofo and JVB logs, if not then clear the logs of prosody, jicofo and JVBs as follwoing then share the logs again

sudo /etc/init.d/prosody stop
sudo /etc/init.d/jicofo stop
sudo /etc/init.d/jitsi-videobridge2 stop
sudo rm -rf /var/log/jitsi/*
sudo rm -rf /var/log/prosody/*
sudo /etc/init.d/prosody start
sudo /etc/init.d/jicofo start
sudo /etc/init.d/jitsi-videobridge2 start

You can also reach me privatly and we can troubleshoot this issue together.

Best Regards,
Mohamed Abada