Configure Jitsi authentication and guests mode gives an error

[razerrazer]

Hello,

I try to get my matrix-home server to working without any guest autentication for jiitsi, and that you need to login to gain access.

Anyway, I following the guide and added these settings to my vars.yml : https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/configuring-playbook-jitsi.md

matrix_jitsi_enable_auth: true
matrix_jitsi_enable_guests: true
matrix_jitsi_prosody_auth_internal_accounts:
  - username: "jitsi-moderator"
    password: "secret-password"
  - username: "another-user"
    password: "another-password"

But when i running the playbook i get an error (I have also try to change the password and also using everything default). My playbook are working without any problems except of this setting.

This is the error output i get from ansible:

TASK [matrix-jitsi : Ensure Jitsi internal authentication users are configured] **************************************************************************************************
failed: [matrix.hostlocal.local] (item={'username': 'jitsi-moderator', 'password': 'secret-password'}) => changed=true 
  ansible_loop_var: item
  cmd: docker exec matrix-jitsi-prosody prosodyctl --config /config/prosody.cfg.lua register jitsi-moderator meet.jitsi 'secret-password'
  delta: '0:00:00.555089'
  end: '2022-01-27 12:46:40.387604'
  item:
    password: secret-password
    username: jitsi-moderator
  msg: non-zero return code
  rc: 1
  start: '2022-01-27 12:46:39.832515'
  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>
changed: [matrix.hostlocal.local] => (item={'username': 'another-user', 'password': 'another-password'})

Let me know if you need more information. Thanks!

[spantaleev]

This is probably a regression since https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1446.

We've seen reports of the same thing in the past as well. If you run --tags=setup-all,start again, it may work.

This should be looked into and fixed. I don't use Jitsi anymore, so I don't know when/if I'll be able to get around to working on it though. Hopefully someone else (or you) can step in and investigate.

[gunwald]

I have the same issue together with some other Jitsi related problems: https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1577 As @spantaleev said, to run --tags=setup-all,start usually runs without the mentioned error. But can't get Jitsi working nevertheless.

[gunwald]

These threads might be related: https://community.jitsi.org/t/cannot-create-rooms-in-self-hosted-instance https://community.jitsi.org/t/jitsi-meet-authentication-not-working-after-update-anyone-can-access

[KarolosLykos]

It seems that you are missing the default {{matrix_base_path}}/config directory. This could happened if you ran the Rebuilding your Jitsi installation instructions but you didn't rebuild the jitsi using the setup-jitsi tag.

To rebuild your Jitsi configuration:

SSH into the server and do this:

• stop all Jitsi services (systemctl stop matrix-jitsi-*).
• remove all Jitsi configuration & data (rm -rf /matrix/jitsi)
• ask Ansible to set up Jitsi anew and restart services (ansible-playbook -i inventory/hosts setup.yml --tags=setup-jitsi,start) <--

[vidlb]

Same problem here, I followed the docs, also tried with manual remove suggested method, and the same error occurred. Looks like the Prosody default config file is missing, isn't it another var to add in vars.yml ?

[vidlb]

The same command works when running an interactive shell in the container. It looks like /config dir is not reachable by prosodyctl when the task is executed via docker exec. This is strange. May be the task is executed too early ? Before the config file is copied ?