WinRM: `init_auth': undefined method `split' for nil:NilClass
When running a kitchen converge on a windows node from my Mac I’m getting the following error when Kitchen attempts to connect via winrm to my ec2 instance. Please note I have proxies involved and are most likely the culprit, but would like to see if its not something I’m doing wrong.
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #converge action: [undefined method `split' for nil:NilClass]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration
Doing some additional digging I attempted to isolate the winrm connection and using the readme I built a ruby script to perform the winrm connection independently:
require 'winrm'
endpoint = 'http://ipaddress:5985/wsman'
winrm = WinRM::WinRMWebService.new(endpoint, :negotiate, :user => 'Administrator', :pass => 'password')
winrm.create_executor do |executor|
executor.run_cmd('ipconfig /all') do |stdout, stderr|
STDOUT.print stdout
STDERR.print stderr
end
end
This returns the following error:
.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/http/transport.rb:231:in `init_auth': undefined method `split' for nil:NilClass (NoMethodError)
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/http/transport.rb:171:in `send_request'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/winrm_service.rb:492:in `send_message'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/winrm_service.rb:393:in `run_wql'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/command_executor.rb:190:in `os_version'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/command_executor.rb:149:in `code_page'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/command_executor.rb:72:in `block in open'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/command_executor.rb:222:in `retryable'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/command_executor.rb:71:in `open'
from ~.chefdk/gem/ruby/2.1.0/gems/winrm-1.8.0/lib/winrm/winrm_service.rb:359:in `create_executor'
from winrm_test.rb:4:in `<main>'`
Reviewing the code, it appears this is the negotiate step, but I don’t have enough knowledge of winrm to know what exactly is failing and it must be nil because r isn’t getting populated.
def init_auth
@logger.debug "Initializing Negotiate for #{@service}"
auth1 = @ntlmcli.init_context
hdr = {"Authorization" => "Negotiate #{auth1.encode64}",
"Content-Type" => "application/soap+xml;charset=UTF-8"
}
@logger.debug "Sending HTTP POST for Negotiate Authentication"
r = @httpcli.post(@endpoint, "", hdr)
verify_ssl_fingerprint(r.peer_cert)
itok = r.header["WWW-Authenticate"].pop.split.last
binding = r.peer_cert.nil? ? nil : Net::NTLM::ChannelBinding.create(r.peer_cert)
auth3 = @ntlmcli.init_context(itok, binding)
{ "Authorization" => "Negotiate #{auth3.encode64}" }
end
Any thoughts, ideas appreciated.
About this issue
- Original URL
- State: open
- Created 8 years ago
- Comments: 23 (10 by maintainers)
Commits related to this issue
- raise a better error if the auth headers cant be parsed as reported in #208 — committed to WinRb/WinRM by mwrock 8 years ago
Just one more case to the list…
I’m using Vagrant with
libvirtprovider on Linux host machine to run guest Windows 2012 R2 and hitting the same issue. The host machine network is behind a proxy - so, it is normal thathttp_proxyandhttps_proxyenvironment variables are set in shell by default to access Internet.This command fails:
Unsetting environment variables (parentheses to unset temporary for
vagrantonly) avoids the problem. This command succeeds:The proxy variables are definitely set correctly because downloads from Internet via
wget(command which also respects these environment variables) work perfectly.Focus
I want to put this focus on the issue: What I don’t get is why HTTP(S) proxy settings are used in non-HTTP(S) protocol communication? Correct me if I’m wrong, but there seems to be absolutely nothing in
winrmto rely on HTTP(S) to actually pick up the proxy settings from thehttp(s)_proxyenvironment variable(s).Note also that I’m not connecting to guest VM over any real network - all communication is local over virtual interfaces (as compared to some cases mentioning AWS above). So, again, since reliance on Internet is ruled out (where HTTP is predominant), there should not be no reason to fail.