Unable to login to console with Ruby 2.2.1 and nexpose gem version 1.0.0 #158
Comments
|
This may not be specific to the gem could you try invoking the api with curl. assuming everything works it should give you the following response. |
|
We took a look at a windows machine running 2.2.1 of ruby with the latest gems and couldn't reproduce the issue you were seeing. By any chance did your hostname point to a location that is not a Nexpose Console. |
|
Ok, using curl (on Windows) I got this: "curl: (56) Received HTTP code 403 from proxy after CONNECT" Using Ruby 1.9.3 and the 0.9.x gem to connect works though. Does 1.0.0 or Ruby 2.2 try to go through the proxy (set in an environment variable) differently by default or something? And no, the hostname is correct. Definitely a Nexpose Console. I also tried using the Console's IP just to be sure. Same result. |
|
1.) Are we talking about trying to Login to a Windows Nexpose Console via a Windows Workstation? 2.) Is the 0.9.x version of the gem is working from IRB, or is it working from a pre-existing script or workflow? 3.) Does the same workstation where curl failed work for the 0.9.x and Ruby 1.9.3 login? 4.) Can you verify the method that Ruby was installed on the workstation? (I'm assuming it's either Ruby Installer or the Rails Installer 5.) Which version of Windows is the workstation/console running? Anything else you can think of to include about the console and the workstation would be welcomed feedback as well. |
|
1.) The Nexpose Console is running on a Linux server. I am connecting via a Windows workstation. 2.) The 0.9.x gem is working from IRB and existing scripts. 3.) Yes, on the same workstation, curl login fails, but logging in with the 0.9.x gem and Ruby 1.9.3 works. 4.) I used the Ruby Installer (from rubyinstaller.org) 5.) The workstation is running Windows 7. The Console is running on Ubuntu 12.04 LTS. We use a proxy server (defined in the system environment variables), but it is not between the workstation and console. |
|
K - It appears as if the new installed version of Ruby is not picking up those system environment variables (by which i'm assuming we're talking about the windows environment variables). This would explain why curl and 1.0.x gem are failing, but 0.9.x is working. 1.) For each Ruby version, are they both running from 'Command Prompt'/Powershell or are you using Cygwin/MinGW? 2.) Can you give us an idea of what is set in the environment variable? Is it just like a different path for the proxy, or is it some kinda authentication? 3.) Is there a way for you to verify that all the environment variables are showing up for each terminal that you're running Ruby from? (For example on linux, typing |
|
Yes, the windows environment variables %HTTP_PROXY% and %HTTPS_PROXY% contain the proxy urls. 1.) I'm running both ruby versions from a Powershell prompt. 2.) The proxy urls point to the same hostname, but different ports for http and https. 3.) I can double-check the environment variables, but I used the same Powershell window for testing both Ruby versions. |
|
K, let's double check the environment variables for each of the powershell windows and then continue troubleshooting from there. I'm pretty confident that's where the problem is situated, and isn't anything directly tied to Ruby2.2 or the Nexpose gem. |
|
The "env" command works in Powershell too. Both the proxy variables are definitely showing up in the powershell window. |
|
@Red5d do the proxy variables show up in |
|
Yes, they do. Both proxy variables are showing up in the output from that. |
|
@Red5d - I think we're running out of ideas. Is it possible for you to email us the script, with the sensitive info removed? |
|
I'm literally using the lines for logging in from the documentation: |
|
Last thing to verify can you open your browser and go to this address for your console. |
|
@Red5d can you test with the old version of the gem (0.9.x) on Ruby 2.2.1. |
|
@asalazar-r7 , yes. That's the message that I get. @erran-r7 , Just tested Ruby 2.2.1 with Nexpose gem version 0.9.5 (the version that I'm currently using successfully on ruby 1.9.3), and it gave the same error as with the 1.0 gem. This does appear to be an issue with the newer Ruby picking up the proxy variables differently or something. Any ideas on that? Thanks for the debugging assistance. I won't take up any more of your time after this since it's probably not a Nexpose gem issue. |
|
@Red5d I'd be interested in seeing the results of this script on both versions of the gem (0.9.x on 1.9.3), filtering out any sensitive information. proxy_keys = %w(HTTP_PROXY HTTPS_PROXY)
proxy_keys.each { |key| puts "#{key} => #{ENV[key].inspect}" }
require 'nexpose'
connection = Nexpose::Connection.new('<ip address>', 'username', 'password')
begin
connection.login
rescue Nexpose::APIError => e
puts "~> #{e.class}: #{e.message}\n\t#{e.backtrace.join("\n\t")}"
end |
|
@erran-r7 , the first part outputs the http/https proxy variable contents correctly for both Ruby versions on gem version 0.9.5. The second part with the login (starting at "begin"), fails with the same error as before on Ruby 2.2.1 (gem 0.9.5), and successfully logs in with Ruby 1.9.3 (gem 0.9.5). |
|
@Red5d maybe one last thing to check, do you have windows (or any) firewall running? |
|
@Red5d - if you're okay with it, i'm going to close the issue for now. Feel free to re-open or comment if anything new comes to light. |
|
Ok, I figured it out. I had to blank the http_proxy and https_proxy environment variables from Ruby like this: After that, logging into Nexpose with the new gem/ruby version worked just fine. |
|
@Red5d glad to here your proxy issue has been resolved. Thanks for posting your solution! 👍 |
|
@Red5d good to hear! thanks! |
When I try to log into the console using version 1.0.0 of the gem and Ruby 2.2.1 from either irb or a script, I get the following error:
This error does not occur with Ruby 1.9.3 and an 0.9.x version of the gem. I've tried logging in with two different user accounts and tried both the DNS name and IP for the console, but I get the same error.
The text was updated successfully, but these errors were encountered: