-
Notifications
You must be signed in to change notification settings - Fork 897
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't use special characters in ansible passwords #18092
Conversation
The rabbitmq password has always needed to be URL-safe, but recently the tower team added a preflight-check in their setup playbook which just bans all special characters. This was causing setup failures even though our passwords were URL safe. Now, we just generate hex passwords. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
I thought we were, but then a schema change was backported, so I guess we can backport whatever is needed ¯\_(ツ)_/¯ Is a data migration good enough, or do we need to tell more things that the rabbit password has changed? |
I think the data migration should do the job. When we upgrade the tower version we re-run the setup playbook. The ansible engineers said that running the playbook with the new password should reset it for everyone that needs it. |
Don't use special characters in ansible passwords (cherry picked from commit 0a6e60e) https://bugzilla.redhat.com/show_bug.cgi?id=1638009
Hammer backport details:
|
If the current rabbitmq password contains special characters it will fail a new preflight check in the setup playbook. This is fixed for new installations by ManageIQ/manageiq#18092 but because we re-run the setup playbook when we upgrade the tower version, we also need to correct existing ones. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
If the current rabbitmq password contains special characters it will fail a new preflight check in the setup playbook. This is fixed for new installations by ManageIQ/manageiq#18092 but because we re-run the setup playbook when we upgrade the tower version, we also need to correct existing ones. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
If the current rabbitmq password contains special characters it will fail a new preflight check in the setup playbook. This is fixed for new installations by ManageIQ/manageiq#18092 but because we re-run the setup playbook when we upgrade the tower version, we also need to correct existing ones. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
If the current rabbitmq password contains special characters it will fail a new preflight check in the setup playbook. This is fixed for new installations by ManageIQ/manageiq#18092 but because we re-run the setup playbook when we upgrade the tower version, we also need to correct existing ones. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
If the current rabbitmq password contains special characters it will fail a new preflight check in the setup playbook. This is fixed for new installations by ManageIQ/manageiq#18092 but because we re-run the setup playbook when we upgrade the tower version, we also need to correct existing ones. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
If the current rabbitmq password contains special characters it will fail a new preflight check in the setup playbook. This is fixed for new installations by ManageIQ/manageiq#18092 but because we re-run the setup playbook when we upgrade the tower version, we also need to correct existing ones. https://bugzilla.redhat.com/show_bug.cgi?id=1638009
The rabbitmq password has always needed to be URL-safe, but recently
the tower team added a preflight-check in their setup playbook which
just bans all special characters.
This was causing setup failures even though our passwords were URL
safe.
Now, we just generate hex passwords.
https://bugzilla.redhat.com/show_bug.cgi?id=1638009
Also of note, this change will cause upgrades to fail so this will also either require a data migration, or we can check and change the password in the code here if we are being strict about no more migrations in the hammer branch. @Fryguy @bdunne thoughts here?