search

spantaleev / matrix-docker-ansible-deploy

🐳 Matrix (An open network for secure, decentralized communication) server setup using Ansible and Docker
GNU Affero General Public License v3.0
4.91k stars 1.05k forks source link

"The given hostname does not exist in the config" when updating Jitsi #1474

Open ubergeek77 opened 2 years ago

ubergeek77 commented 2 years ago

(as far as I'm aware, this issue is related to this recent PR: https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1446)

I am not sure why, but this change resulted in an error when updating my stack. The error came from prosody:

The given hostname does not exist in the config

Upon inspecting the prosody config, meet.jitsi indeed did not exist. However, auth.meet.jitsi did exist.

To work around this, I modified the following line, to change the hostname passed to prosody from meet.jitsi to auth.meet.jitsi:

https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/6e38ce42d880d23c574d084c666060e17f0924a6/roles/matrix-jitsi/tasks/util/setup_jitsi_auth.yml#L18

--- shell: "docker exec matrix-jitsi-prosody prosodyctl --config /config/prosody.cfg.lua register {{ item.username | quote }} meet.jitsi {{ item.password | quote }}"
+++ shell: "docker exec matrix-jitsi-prosody prosodyctl --config /config/prosody.cfg.lua register {{ item.username | quote }} auth.meet.jitsi {{ item.password | quote }}"

With this change, the stack update was able to proceed and succeeded without errors - but I am not able to log in to Jitsi using the new credentials I set via matrix_jitsi_prosody_auth_internal_accounts.

However, my old credentials set before this stack update (and before this new change) remain functional. For reference, in the volume for my stack's prosody instance, my credentials were not stored under auth.meet.jitsi or meet.jitsi, but rather matrix.jitsi.web (/config/data/matrix%2djitsi%2dweb/accounts).

Notably, I could not specify matrix.jitsi.web in setup_jitsi_auth.yml:18, it resulted in the same error as above.

If I take the .dat that was created by ansible under /config/data/auth%2emeet%2ejitsi/accounts, and copy it to /config/data/matrix%2djitsi%2dweb/accounts, the new credentials will work perfectly. So while my Jitsi instance is reading credentials from the old directory, prosodyctl is not able to create new accounts to this directory.

Is it possible there is a backwards compatibility issue with this change, such that stacks older than a certain commit will not update perfectly?

As a side note, despite already having set a user account manually before this stack update, ansible did not recognize it, and I was required to set a new account via matrix_jitsi_prosody_auth_internal_accounts (which, due to this issue, does not work).

To reduce friction from older stacks updating to this change, I would like to additionally suggest that the stack checks for existing accounts directly in the container's /config directory, before requiring one to be set in matrix_jitsi_prosody_auth_internal_accounts, especially since passwords are in plaintext in vars.yml, but encrypted in prosody's .dat format.

ubergeek77 commented 2 years ago

Upon closer inspection, this was caused by me coming from an older version of Jitsi, and ansible not starting the newer version before attempting to use prosodyctl.

Since setup-all does not restart to newer versions of services like start does, while the stack and its configs will be updated, any code that needs to run during setup-all will not be run against the new services, they will be run against the old services (at least in my case).

So, the solution was to run setup-all, start, then setup-all again (I added an additional start for good measure):

ansible-playbook -i inventory/hosts setup.yml --tags=setup-all
ansible-playbook -i inventory/hosts setup.yml --tags=start
ansible-playbook -i inventory/hosts setup.yml --tags=setup-all
ansible-playbook -i inventory/hosts setup.yml --tags=start

I am unsure if this would have been possible had I not used my workaround to get my stack to succeed the first time.

In any case, this was the problem.

Perhaps the maintenance guide could be updated with this warning? Or, would there be a way to ensure setup-all does not erroneously run against older service versions using scripts not intended for those versions?