Bug 1430701 - Failure to fetch v2_key prevents relaunching appliance_console
Summary: Failure to fetch v2_key prevents relaunching appliance_console
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: GA
: 5.9.0
Assignee: Gregg Tanzillo
QA Contact: luke couzens
URL:
Whiteboard: black
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-09 11:00 UTC by luke couzens
Modified: 2018-03-01 13:10 UTC (History)
7 users (show)

Fixed In Version: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-01 13:10:28 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0380 0 normal SHIPPED_LIVE Moderate: Red Hat CloudForms security, bug fix, and enhancement update 2018-03-01 18:37:12 UTC

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


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