Guide how to limit users with mod_muc_max_occupants.lua

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 XMPP error reply received from 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;

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/ and tried to restart prosody services, which failed. Added 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 :

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/ but that just threw thousands of errors in the logs.
  • change storage = "memory" in /etc/prosody/conf.avail/
  • add cross_domain_bosh = false; and consider_bosh_secure = true; to /etc/prosody/conf.avail/

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 -O- | sudo apt-key add -
$ nano /etc/apt/sources.list
$ deb bionic main
$ sudo apt-get update
$ prosodyctl cert generate
$ 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

@Mohamed_Abada and @gpatel-fr thank you both again.

I’ve made the changes you suggested Mohamed and these are the logs:

I’m not sure how to resolve this. I’ve tried adding component_ports = { 5347 } to prosody.cfg.lua

highly dubious that this could be a fix. Why don’t you post also prosody.err ? it’s clear that prosody don’t work, so jicofo and jvb are not likely to work anyway, but prosody.err may have more interesting info.

prosody.err is empty, which I thought was strange?

your prosody seems to be doing so little it can’t even throw a decent error.
Right, here is my prosody.conf

grep -v “--” prosody.cfg.lua | grep -v -e ‘^$’

admins = { }
modules_enabled = {
modules_disabled = {
allow_registration = false
daemonize = true;
pidfile = "/var/run/prosody/";
c2s_require_encryption = true
s2s_require_encryption = true
s2s_secure_auth = false
authentication = "internal_hashed"
log = {
	info = "/var/log/prosody/prosody.log";
	error = "/var/log/prosody/prosody.err";
	{ levels = { "error" }; to = "syslog";  };
certificates = "certs"
Include "conf.d/*.cfg.lua"

do you see a significant difference ?
is there only symbolic links in conf.d to files in conf.available ?

I can limit the number of users :pray:

@gpatel-fr this was my prosody.cfg.lua, I added Include "conf.d/*.cfg.lua" to the bottom of the file, restarted and was able to limit the users.

admins = { }
cross_domain_bosh = false;
component_ports = { 5347 }
modules_enabled = {
modules_disabled = {
allow_registration = false
c2s_require_encryption = true
s2s_require_encryption = true
s2s_secure_auth = false
pidfile = "/var/run/prosody/"
authentication = "internal_hashed"
archive_expires_after = "1w"
log = {
	info = "/var/log/prosody/prosody.log";
	error = "/var/log/prosody/prosody.err";
certificates = "certs"
VirtualHost "localhost"

My prosody.err is still empty and there are errors in the console but it feels like progress! These are my jvb.log, jicofo.log and prosody.log following the successful limit of users.

In the jvb.log I’m seeing the following being reported every 10 seconds:

2020-06-07 16:06:15.672 INFO: [18] Videobridge.createConference#320: create_conf, id=b88b2478c2e8f036 gid=null logging=false
2020-06-07 16:06:15.679 INFO: [18] Performed a successful health check in PT0.007S. Sticky failure: false
1 Like