Description of problem:invalid ip when fetching v2_key crashes appliance console Version-Release number of selected component (if applicable):5.4.5.2 How reproducible:100% Steps to Reproduce: 1.ssh to configured appliance 2.start appliance_console 3.generate custom encryption key 4.fetch key from remote machine 5.provide invalid ip (192.168.2.01) 6.use defaults for rest Actual results:appliance console crashes Expected results:please provide valid ip address Additional info:Generate Custom Encryption Key Encryption Key 1) Create key 2) Fetch key from remote machine Choose the encryption key: |1| 2 Enter the hostname for appliance with v2_key: 192.168.2.01 Enter the appliance SSH login: |root| Enter the appliance SSH password: ******* Enter the path of remote v2_key: |/var/www/miq/vmdb/certs/v2_key| /opt/rh/cfme-gemset/gems/net-ssh-2.9.4/lib/net/ssh/transport/session.rb:70:in `initialize': Connection timed out - connect(2) (Errno::ETIMEDOUT) from /opt/rh/cfme-gemset/gems/net-ssh-2.9.4/lib/net/ssh/transport/session.rb:70:in `open' from /opt/rh/cfme-gemset/gems/net-ssh-2.9.4/lib/net/ssh/transport/session.rb:70:in `block in initialize' from /opt/rh/ruby200/root/usr/share/ruby/timeout.rb:52:in `timeout' from /opt/rh/ruby200/root/usr/share/ruby/timeout.rb:97:in `timeout' from /opt/rh/cfme-gemset/gems/net-ssh-2.9.4/lib/net/ssh/transport/session.rb:67:in `initialize' from /opt/rh/cfme-gemset/gems/net-ssh-2.9.4/lib/net/ssh.rb:207:in `new' from /opt/rh/cfme-gemset/gems/net-ssh-2.9.4/lib/net/ssh.rb:207:in `start' from /opt/rh/cfme-gemset/gems/net-scp-1.2.1/lib/net/scp.rb:202:in `start' from /var/www/miq/lib/appliance_console/key_configuration.rb:82:in `fetch_key' from /var/www/miq/lib/appliance_console/key_configuration.rb:52:in `activate' from /var/www/miq/lib/appliance_console/key_configuration.rb:44:in `block in ask_question_loop' from /var/www/miq/lib/appliance_console/key_configuration.rb:42:in `loop' from /var/www/miq/lib/appliance_console/key_configuration.rb:42:in `ask_question_loop' from /var/www/miq/lib/appliance_console.rb:462:in `block (2 levels) in <module:ApplianceConsole>' from /var/www/miq/lib/appliance_console.rb:192:in `loop' from /var/www/miq/lib/appliance_console.rb:192:in `block in <module:ApplianceConsole>' from /var/www/miq/lib/appliance_console.rb:165:in `loop' from /var/www/miq/lib/appliance_console.rb:165:in `<module:ApplianceConsole>' from /var/www/miq/lib/appliance_console.rb:164:in `<main>' [root@10-16-6-30 ~]#
BZ also in 5.5.3.2
I can reproduce this with capablanca-2. I propose to just catch the exception we get from Net::SCP. The connection may get refused no matter how much validation we do. Then, we can improve UX by not allowing user to fill other properties until (s)he submits something ping-able.
https://github.com/ManageIQ/manageiq/pull/7818
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/2b74db8a2ed66cd317e18adb44943bfb8806b1aa commit 2b74db8a2ed66cd317e18adb44943bfb8806b1aa Author: Šimon Lukašík <isimluk> AuthorDate: Fri Apr 8 14:20:17 2016 +0200 Commit: Šimon Lukašík <isimluk> CommitDate: Sat Apr 9 14:30:09 2016 +0200 Rescue the error when connection timed-out Addressing: net/ssh/transport/session.rb:70:in `initialize': Connection timed out - connect(2) (Errno::ETIMEDOUT) Auditing the SCP gem and dependencies, I see a lot of potential exceptions that may occur: Net::SCP::Error, Net::SSH::Exception, SystemCallError, SocketError and perhaps more. They all have one common superclass that is StandardError. https://bugzilla.redhat.com/show_bug.cgi?id=1321107 gems/pending/appliance_console/key_configuration.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Verified in 5.6.0.4-beta2.3
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/RHBA-2016:1348
*** Bug 1357589 has been marked as a duplicate of this bug. ***