jitsi meet issue

[ncamacho97]

Playbook Configuration:

My vars.yml file looks like this:

---
    # The bare domain name which represents your Matrix identity.
    # Matrix user ids for your server will be of the form (`@user:<matrix-domain>`).
    #
    # Note: this playbook does not touch the server referenced here.
    # Installation happens on another server ("matrix.<matrix-domain>").
    #
    # If you've deployed using the wrong domain, you'll have to run the Uninstalling step,
    # because you can't change the Domain after deployment.
    #
    # Example value: example.com
    matrix_domain: syop.xyz

    # The Matrix homeserver software to install.
    # See:
    #  - `roles/custom/matrix-base/defaults/main.yml` for valid options
    # - the `docs/configuring-playbook-IMPLEMENTATION_NAME.md` documentation page, if one is available for your implementation choice
    matrix_homeserver_implementation: synapse

    # A secret used as a base, for generating various other secrets.
    # You can put any string here, but generating a strong one is preferred (e.g. `pwgen -s 64 1`).
    matrix_homeserver_generic_secret_key: mykeys

    # This is something which is provided to Let's Encrypt when retrieving SSL certificates for domains.
    #
    # In case SSL renewal fails at some point, you'll also get an email notification there.
    #
    # If you decide to use another method for managing SSL certificates (different than the default Let's Encrypt),
    # you won't be required to define this variable (see `docs/configuring-playbook-ssl-certificates.md`).
    #
    # Example value: someone@example.com
    matrix_ssl_lets_encrypt_support_email: 'my@email.com'

    # A Postgres password to use for the superuser Postgres user (called `matrix` by default).
    #
    # The playbook creates additional Postgres users and databases (one for each enabled service)
    # using this superuser account.
    devture_postgres_connection_password: 'mykeys'

    matrix_jitsi_enabled: true

    # Run `bash inventory/scripts/jitsi-generate-passwords.sh` to generate these passwords,
    # or define your own strong passwords manually.
    matrix_jitsi_jicofo_auth_password: mykeys
    matrix_jitsi_jvb_auth_password: mykeys
    matrix_jitsi_jibri_recorder_password: mykeys
    matrix_jitsi_jibri_xmpp_password: mykeys

    matrix_prometheus_enabled: true

    # You can remove this, if unnecessary.
    prometheus_node_exporter_enabled: true

    # You can remove this, if unnecessary.
    prometheus_node_exporter_enabled: true

    grafana_enabled: true

    grafana_anonymous_access: false

    # This has no relation to your Matrix user id. It can be any username you'd like.
    # Changing the username subsequently won't work.
    grafana_default_admin_user: 'nick'

    # Changing the password subsequently won't work.
    grafana_default_admin_password: mykeys

    matrix_registration_enabled: true

    # Generate a strong secret using: `pwgen -s 64 1`.
    matrix_registration_admin_secret: mykeys

    matrix_mautrix_telegram_enabled: true
    matrix_mautrix_telegram_api_id: 'mykeys'
    matrix_mautrix_telegram_api_hash: 'mykeys'

    matrix_synapse_ext_password_provider_shared_secret_auth_enabled: true
    matrix_synapse_ext_password_provider_shared_secret_auth_shared_secret: mykeys

    matrix_synapse_admin_enabled: true
    matrix_jitsi_disable_gravatar: false
    matrix_jitsi_enable_lobby: true

Matrix Server:

• Ubuntu 21.04
• amd64

Problem description: I know you said you don't use jitsi but since the new update I have lost getting moderator when opening a room :(

p.s i already ask the docker-jitsi-meet maker said its some auth that was not set up i guess :/

[spantaleev]

It may be related to a Jitsi upgrade, like https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2436

.. or to Matrix Authentication Support for Jitsi - https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2375

[Geosearchef]

I'm encountering the same issue, when using the internal authentication mechanism.

[briankendall]

I was about to report I couldn't get Jitsi working either because of something going wrong when setting up internal auth, but then I added the following to my playbook to try and get a better idea of what was going wrong, and it seemingly fixed it!

setup_jitsi_auto_internal.no_log: false
no_log: false

A heisenbug, perhaps?

(Not sure if this is related to the earlier Jitsi issues I was having, #2368.)

edit: Just realized there's a typo in setup_jitsi_auto_internal.no_log, meant to type setup_jitsi_auth_internal.no_log. So that makes this even more mysterious?

[Geosearchef]

@briankendall Were you having problems with moderation rights or with installation in general?

I'm asking as I also encountered an error telling me to enable logging during the initial installation in the internal Auth user setup. I fixed it by following the "rebuilding the installation" steps. Could've been just luck and a Heisenbug on the second try (although I didn't observe it, just retried).

[briankendall]

It was an issue with installation in general, and I think I got confused about what issue you were reporting. I had Jitsi set up before, pulled the latest changes to matrix-docker-ansible-deploy a few months ago and suddenly it broke Jitsi and couldn't set up it any longer without producing an inscrutable error. I sat on it for another two months, pulled the latest changes and tried again, and got an error when setting up internal auth the first two or three times I tried running setup-all, but then it worked after that. No idea why!

However, now that Jitsi is up and running again, I realize that I have the same issue as you -- I have no moderation rights when I start a meeting.

edit: I just tried following the steps for rebuilding the jitsi installation. The first time I got that error when setting up internal auth again. The second time it worked, except once again I have no moderation rights.

[briankendall]

Since I found out how to reproduce the error, this time I just manually edited no_log in roles/custom/matrix-jitsi/tasks/util/prosody_post_setup_hooks/setup_jitsi_auth_internal.yml to be false, and got the following:

failed: [matrix.mydomain.com] (item={'username': 'my_user', 'password': 'my_pass'}) => changed=false
  ansible_loop_var: item
  cmd: /usr/bin/env docker exec matrix-jitsi-prosody prosodyctl --config /config/prosody.cfg.lua register my_user meet.jitsi my_pass
  delta: '0:00:00.658826'
  end: '2023-02-20 09:40:53.619053'
  item:
    password: my_pass
    username: my_user
  msg: non-zero return code
  rc: 1
  start: '2023-02-20 09:40:52.960227'
  stderr: ''
  stderr_lines: <omitted>
  stdout: |2-

    **************************
    Prosody was unable to find the configuration file.
    We looked for: /etc/prosody//config/prosody.cfg.lua
    A sample config file is included in the Prosody download called prosody.cfg.lua.dist
    Copy or rename it to prosody.cfg.lua and edit as necessary.
    More help on configuring Prosody can be found at https://prosody.im/doc/configure
    Good luck!
    **************************
  stdout_lines: <omitted>

Can't say for sure this is related to the issue with not having moderation rights, but something is certainly going wrong with internal auth.

[Geosearchef]

The docker command run there by the playbook seems to contain a superfluous / for the config parameter. ("or doesn't support absolute paths) Seems to be from here: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/d7e69cfa1ebebb5ec8d1b383cf5981ea9709f15a/roles/custom/matrix-jitsi/tasks/util/prosody_post_setup_hooks/setup_jitsi_auth_internal.yml#L7

It looks like it already was that way before matrix Auth support for Jitsi was added though.

(although I suspect it's unrelated to the moderator issue)

[spantaleev]

Are you hitting some error when running this command as is? Why shouldn't it support absolute paths?

/config inside this matrix-jitsi-prosody container is mounted like this: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/1c10a7727c82028b5b997ebe328d19db17d52b96/roles/custom/matrix-jitsi/templates/prosody/matrix-jitsi-prosody.service.j2#L27

And this is the path variable definition: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/1c10a7727c82028b5b997ebe328d19db17d52b96/roles/custom/matrix-jitsi/defaults/main.yml#L199-L200

The /config/prosody.cfg.lua path in the container should ultimately lead to /matrix/jitsi/prosody/config/prosody.cfg.lua outside of it.

---

Perhaps meet.jitsi could be replaced with {{ matrix_jitsi_xmpp_domain }} however. matrix_jitsi_xmpp_domain has the same value (meet.jitsi) by default, but.. if someone changes it, this command will probably stop working.

[Geosearchef]

Why shouldn't it support absolute paths?

Yeah, I'm wondering that too, especially as it sometimes works. But the log clearly shows, that the path was interpreted incorrectly:

Prosody was unable to find the configuration file.
We looked for: /etc/prosody//config/prosody.cfg.lua

@briankendall Can you take a look at the result of executing the command manually?

[spantaleev]

Sounds like a Jitsi regression, if it's trying to access /etc/prosody//config/prosody.cfg.lua instead of /config/prosody.cfg.lua

[briankendall]

I executed the following on my server:

docker exec matrix-jitsi-prosody prosodyctl --config /config/prosody.cfg.lua register testuser meet.jitsi testpass

and it executed without errors. Furthermore, if I log in as the user I made when connecting to my jitsi instance, I have moderator rights.

I tried using prosodyctl to manually remove and re-add my proper user account, and while it also worked without errors, that user still didn't have moderator rights.

[ebildebil]

I still can't get moderator rights and I use internal auth. Anyone know if there is any solution to this now?

[patrickstump]

I've been working on what I think is the same issue in #2589 . I setup the stock jitsi server from their docker install and compared configs and env variables.

I turned off authentication, deleted configs. I get the same effect with auth being ldap or internal or setting auth to "".

So to recap, I cannot get moderator when creating a room whether I use matrix_jitsi_enable_auth as true or false. I posted this in the other thread as well, but this is the only difference between the stock docker install and this ansible install. In the jicofo log this happens after "Join Room" whether using authentication or not.

Jicofo 2023-04-01 21:02:35.418 SEVERE: [46] ChatRoomRoleManager.grantOwner#45: Failed to grant owner status to ujctir_r3afx1lh--9tt3jwf@meet.jitsi/A_fkTHs-B9SP
java.lang.RuntimeException: Failed to grant owner: <iq xmlns='jabber:client' to='focus@auth.meet.jitsi/focus' from='compellingboostscomfortwhatsoever@muc.meet.jitsi' id='7RSG8-189' type='error'><error type='modify'><not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></iq>
    at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.grantOwnership(ChatRoomImpl.java:529)
    at org.jitsi.jicofo.xmpp.muc.ChatRoomRoleManager.grantOwner(ChatRoomRoleManager.kt:42)
    at org.jitsi.jicofo.xmpp.muc.AutoOwnerRoleManager.electNewOwner(ChatRoomRoleManager.kt:106)
    at org.jitsi.jicofo.xmpp.muc.AutoOwnerRoleManager.memberJoined(ChatRoomRoleManager.kt:68)
    at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.lambda$processOtherPresence$12(ChatRoomImpl.java:856)
    at org.jitsi.utils.event.SyncEventEmitter$fireEvent$1$1.invoke(EventEmitter.kt:64)
    at org.jitsi.utils.event.SyncEventEmitter$fireEvent$1$1.invoke(EventEmitter.kt:64)
    at org.jitsi.utils.event.BaseEventEmitter.wrap(EventEmitter.kt:49)
    at org.jitsi.utils.event.SyncEventEmitter.fireEvent(EventEmitter.kt:64)
    at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.processOtherPresence(ChatRoomImpl.java:855)
    at org.jitsi.impl.protocol.xmpp.ChatRoomImpl.processPresence(ChatRoomImpl.java:909)
    at org.jivesoftware.smackx.muc.MultiUserChat$3.processStanza(MultiUserChat.java:309)
    at org.jivesoftware.smack.AbstractXMPPConnection.lambda$invokeStanzaCollectorsAndNotifyRecvListeners$8(AbstractXMPPConnection.java:1619)
    at org.jivesoftware.smack.AsyncButOrdered$Handler.run(AsyncButOrdered.java:151)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:829)

I'm at a loss at this point.

[briankendall]

Any movement on this issue?

[aptiko]

I suggest to close this issue, as there is more information on #2589. Granted, there are many issues with jitsi authentication, and this ticket deals with many of them, which doesn't help.