Bug 1430701

Summary: Failure to fetch v2_key prevents relaunching appliance_console
Product: Red Hat CloudForms Management Engine Reporter: luke couzens <lcouzens>
Component: ApplianceAssignee: Gregg Tanzillo <gtanzill>
Status: CLOSED ERRATA QA Contact: luke couzens <lcouzens>
Severity: medium Docs Contact:
Priority: high    
Version: 5.8.0CC: abellott, gblomqui, jhardy, jkrocil, obarenbo, simaishi, yrudman
Target Milestone: GA   
Target Release: 5.9.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: black
Fixed In Version: 5.9.0.1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-01 13:10:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description luke couzens 2017-03-09 11:00:51 UTC
Description of problem:Failing to fetching v2_key prevents relaunching appliance_console


Version-Release number of selected component (if applicable):5.8.0.4


How reproducible:100%


Steps to Reproduce:
1.provision appliance
2.setup database
3.generate new v2_key
4.fetch it from bogus machine
5.say no to try again
6.exit appliance_console
7.Launch appliance_console

Actual results:/var/www/miq/vmdb/certs/v2_key doesn't exist!


Expected results:appliance_console should launch


Additional info:
launching appliance_console after failing to fetch v2_key:
http://pastebin.test.redhat.com/462937

once this key has been removed there is no way to generate a new key to fix this issue, even copying a v2_key from another appliance fails as it can't decrypt it.

When fetching a key the option says it will overwrite the current key, but it seems it remove the old key regardless if it fetches a new one. It should only remove/replace if it fetches a correct key, or it should move the first key to v2_key.old so we can still recover from said issues.

Comment 2 luke couzens 2017-03-09 12:51:31 UTC
My additional info was slightly miss leading.

Once this key has been removed there is no way to generate a new key to fix the issue, if we copy a v2_key from another appliance or generate a new key with 'fix_auth -k' followed by 'fix_auth --invalid bogus' it still fails to launch appliance_console complaining it can't decrypt using the new key.

'fix_auth invalid' should fix this decrypt issue but does not.

Comment 5 CFME Bot 2017-06-21 16:13:22 UTC
New commit detected on ManageIQ/manageiq-gems-pending/master:
https://github.com/ManageIQ/manageiq-gems-pending/commit/4e904cdcc2e14d8061081000eeb277cad8930a37

commit 4e904cdcc2e14d8061081000eeb277cad8930a37
Author:     Bo Yao <boyao>
AuthorDate: Thu Jun 15 10:56:55 2017 -0400
Commit:     Bo Yao <boyao>
CommitDate: Mon Jun 19 14:52:09 2017 -0400

    get new v2_key as temp and replace only when success
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1430701

 .../pending/appliance_console/key_configuration.rb | 36 +++++++++++++---------
 1 file changed, 22 insertions(+), 14 deletions(-)

Comment 6 CFME Bot 2017-06-21 16:13:26 UTC
New commit detected on ManageIQ/manageiq-gems-pending/master:
https://github.com/ManageIQ/manageiq-gems-pending/commit/33e69a991e5a279381bb5d2f49b33c43b247ddf0

commit 33e69a991e5a279381bb5d2f49b33c43b247ddf0
Author:     Bo Yao <boyao>
AuthorDate: Mon Jun 19 14:00:54 2017 -0400
Commit:     Bo Yao <boyao>
CommitDate: Mon Jun 19 14:52:19 2017 -0400

    update spec for new key_configuration
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1430701

 spec/appliance_console/key_configuration_spec.rb | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

Comment 7 CFME Bot 2017-06-21 16:13:32 UTC
New commit detected on ManageIQ/manageiq-gems-pending/master:
https://github.com/ManageIQ/manageiq-gems-pending/commit/28296401889db6e49aca3d63d9fb113e54ddb60a

commit 28296401889db6e49aca3d63d9fb113e54ddb60a
Author:     Bo Yao <boyao>
AuthorDate: Wed Jun 21 09:52:16 2017 -0400
Commit:     Bo Yao <boyao>
CommitDate: Wed Jun 21 09:52:16 2017 -0400

    changes according to Nick's review
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1430701

 .../pending/appliance_console/key_configuration.rb | 26 +++++++++++++---------
 1 file changed, 15 insertions(+), 11 deletions(-)

Comment 9 CFME Bot 2017-06-23 13:18:19 UTC
New commit detected on ManageIQ/manageiq-gems-pending/master:
https://github.com/ManageIQ/manageiq-gems-pending/commit/b91ea49dbcbe95eb312b602f53e3f14c5f3a6c87

commit b91ea49dbcbe95eb312b602f53e3f14c5f3a6c87
Author:     Nick Carboni <ncarboni>
AuthorDate: Wed Jun 21 12:10:42 2017 -0400
Commit:     Nick Carboni <ncarboni>
CommitDate: Wed Jun 21 14:01:19 2017 -0400

    Consider database.yml not configured if we don't have a v2_key
    
    This becomes an issue in the unlikely scenario where a v2_key
    is not present, but there are v2 encrypted strings in database.yml
    
    This allows the user to create a new v2_key using the console which
    would previously fail to even start in this situation.
    
    Follow up to #211
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1430701

 lib/gems/pending/appliance_console/database_configuration.rb | 3 ++-
 spec/appliance_console/database_configuration_spec.rb        | 7 ++++++-
 2 files changed, 8 insertions(+), 2 deletions(-)

Comment 10 luke couzens 2017-10-11 10:06:18 UTC
Verified in 5.9.0.1

Comment 14 errata-xmlrpc 2018-03-01 13:10:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0380