Red Hat Bugzilla – Bug 1430701
Failure to fetch v2_key prevents relaunching appliance_console
Last modified: 2018-03-01 08:10:28 EST
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.
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.
https://github.com/ManageIQ/manageiq-gems-pending/pull/211
PR: https://github.com/ManageIQ/manageiq-gems-pending/pull/211
New commit detected on ManageIQ/manageiq-gems-pending/master: https://github.com/ManageIQ/manageiq-gems-pending/commit/4e904cdcc2e14d8061081000eeb277cad8930a37 commit 4e904cdcc2e14d8061081000eeb277cad8930a37 Author: Bo Yao <boyao@redhat.com> AuthorDate: Thu Jun 15 10:56:55 2017 -0400 Commit: Bo Yao <boyao@redhat.com> 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(-)
New commit detected on ManageIQ/manageiq-gems-pending/master: https://github.com/ManageIQ/manageiq-gems-pending/commit/33e69a991e5a279381bb5d2f49b33c43b247ddf0 commit 33e69a991e5a279381bb5d2f49b33c43b247ddf0 Author: Bo Yao <boyao@redhat.com> AuthorDate: Mon Jun 19 14:00:54 2017 -0400 Commit: Bo Yao <boyao@redhat.com> 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(-)
New commit detected on ManageIQ/manageiq-gems-pending/master: https://github.com/ManageIQ/manageiq-gems-pending/commit/28296401889db6e49aca3d63d9fb113e54ddb60a commit 28296401889db6e49aca3d63d9fb113e54ddb60a Author: Bo Yao <boyao@redhat.com> AuthorDate: Wed Jun 21 09:52:16 2017 -0400 Commit: Bo Yao <boyao@redhat.com> 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(-)
https://github.com/ManageIQ/manageiq-gems-pending/pull/212
New commit detected on ManageIQ/manageiq-gems-pending/master: https://github.com/ManageIQ/manageiq-gems-pending/commit/b91ea49dbcbe95eb312b602f53e3f14c5f3a6c87 commit b91ea49dbcbe95eb312b602f53e3f14c5f3a6c87 Author: Nick Carboni <ncarboni@redhat.com> AuthorDate: Wed Jun 21 12:10:42 2017 -0400 Commit: Nick Carboni <ncarboni@redhat.com> 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(-)
Verified in 5.9.0.1
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