Bug 1387024 - changing admin password via command line breaks existing accounts
Summary: changing admin password via command line breaks existing accounts
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: cfme-future
Assignee: Gregg Tanzillo
QA Contact: luke couzens
URL:
Whiteboard: cli
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-20 01:25 UTC by Roderick Moore
Modified: 2017-01-11 21:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-11 21:37:24 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:


Attachments (Terms of Use)

Description Roderick Moore 2016-10-20 01:25:11 UTC
Description of problem: I tried to create a CF v5.6.1 appliance with an exported database. After importing the database, I verified that I could log in as cloudops and clouduser. I then ran a command to change the admin password. After doing so I could no longer log in as cloudops or clouduser. I repeated the process with the v5.6.0 appliance and was able to change the admin password without breaking clouduser or cloudops. 


Version-Release number of selected component (if applicable):vsphere appliance v5.6.1


How reproducible:


Steps to Reproduce:
1. import CF v5.6.1 appliance
2. import the offline database provided by the management bu on the following mojo page: https://mojo.redhat.com/docs/DOC-1093580
3. verify that you can login as cloudops with a password of Redhat1!
4. after importing the database, follow the steps to change the admin password in CF 4.x as detailed in the following knowledgebase article: https://access.redhat.com/solutions/801103
5. attempt to login as cloudops

Actual results: incorrect password error encountered


Expected results:


Additional info: same procedure works with CF v5.6.0

Comment 2 Roderick Moore 2016-10-31 15:51:48 UTC
I've repeated this process with the 5.6.2 appliance and it works as expected. In all honesty, I think that this issue may have been caused by disabling the webservices role when attempting to connect to the appliance.

Comment 3 Nick Carboni 2017-01-11 21:37:24 UTC
Closing this as the bug can not be reproduced as originally described.

I believe the failure to log in when the webservices role is disabled is expected behavior, but that should probably be a separate bug if that is an issue.


Note You need to log in before you can comment on or make changes to this bug.