I would like to register private node to open source Chef server. I had problem of making it register to the chef-server as it can’t identify the private IP in my local domain. I don’t have any NAT mechanism implemented on my private node. But it has access to internet. I will be thankful if someone help me in sorting out this issue.
Not quite sure what you mean. Chef Server doesn’t care what the IP address of your node is. Can you paste some error messages?
Hi, I am getting problem with windows node, It is simply specifying connection refused I have enabled all the ports. But I was unable to know how to bootstrap it.
I’m assuming you are trying to connect via WinRM and have enabled ports 5985(HTTP) and 5986(HTTPS) in windows firewall.
Can you share your bootstrap command to help diagnose?
In addition to enabling firewall ports, you want to:
- use the knife-windows
knife bootstrap windows WinRMcommand - unless you are bootstrapping 2012R2 (where it is already enabled), enable WinRM on the node
winrm quickconfig -q - if you are trying to connect via SSL, create an SSL listener
Also see this post covering winrm connectivity and authentication troubleshooting tips.
Matt
Hi Matt_Wrock, Thanks for the response the above helped me to some extent, now I am getting the following error
ERROR: WinRM::WinRMHTTPTransportError: Unable to parse WinRM response: #<ArgumentError: invalid byte sequence in UTF-8>
Could you please help me out in resolving this.
Can you share your boottrapping command and the full error you are receiving? Notably is there text after “#” with the error message and response code?
What version of windows is the node running?
Please find the command and complete error below.
knife bootstrap windows winrm 192.168.1.5 -x DDVN -P !$#Mother -N sample
192.168.1.5 C:\Users\DDVN>goto install
192.168.1.5 Checking for existing downloaded package at "C:\Users\DDVN\AppData\Local\Temp\chef-client-latest.msi"
192.168.1.5 Found existing downloaded package, deleting.
192.168.1.5 Attempting to download client package using PowerShell if available…
192.168.1.5 powershell.exe -ExecutionPolicy Unrestricted -NoProfile -NonInteractive -File C:\chef\wget.ps1 “https://www.chef.io/chef/download?p=windows&pv=200
r2&m=i686&DownloadContext=PowerShell&v=12” "C:\Users\DDVN\AppData\Local\Temp\chef-client-latest.msi"
ERROR: WinRM::WinRMHTTPTransportError: Unable to parse WinRM response: #<ArgumentError: invalid byte sequence in UTF-8>
C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/source.rb:219:in match' C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/source.rb:219:inmatch’
C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/parsers/baseparser.rb:202:in pull_event' C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/parsers/baseparser.rb:183:inpull’
C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/parsers/treeparser.rb:22:in parse' C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/document.rb:283:inbuild’
C:/opscode/chef/embedded/lib/ruby/2.0.0/rexml/document.rb:43:in initialize' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:42:innew’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:42:in response_xml' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:61:inraise_if_wsman_fault’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:51:in raise_if_error' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/http/response_handler.rb:35:inparse_to_xml’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/http/transport.rb:50:in send_request' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/winrm_service.rb:430:insend_message’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-1.3.4/lib/winrm/winrm_service.rb:415:in send_get_output_message' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/winrm-s-0.3.1/lib/winrm/winrm_service_patch.rb:64:inget_command_output’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/winrm_session.rb:61:in get_output' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/winrm_session.rb:52:inrelay_command’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/winrm_knife_base.rb:140:in block in relay_winrm_command' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/winrm_knife_base.rb:138:ineach’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/winrm_knife_base.rb:138:in relay_winrm_command' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/winrm_knife_base.rb:125:inrun_command’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/bootstrap_windows_base.rb:328:in bootstrap' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/knife-windows-1.1.1/lib/chef/knife/bootstrap_windows_winrm.rb:53:inrun’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/chef-12.4.1-universal-mingw32/lib/chef/knife.rb:425:in block in run_with_pretty_exceptions' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/chef-12.4.1-universal-mingw32/lib/chef/local_mode.rb:39:inwith_server_connectivity’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/chef-12.4.1-universal-mingw32/lib/chef/knife.rb:424:in run_with_pretty_exceptions' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/chef-12.4.1-universal-mingw32/lib/chef/knife.rb:215:inrun’
C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/chef-12.4.1-universal-mingw32/lib/chef/application/knife.rb:142:in run' C:/opscode/chef/embedded/lib/ruby/gems/2.0.0/gems/chef-12.4.1-universal-mingw32/bin/knife:25:in<top (required)>'
C:/opscode/chef/embedded/bin/knife:23:in load' C:/opscode/chef/embedded/bin/knife:23:in'
…
invalid byte sequence in UTF-8
Line: 7
I have tried the following command
winrm set winrm/config/service @{AllowUnencrypted=“false”} but it has no impact
Ahh. Looks like you are using the winrm gem version 1.3.4 which had a regression bug in its encoding. This was fixed in v1.3.5 and the latest version is 1.4.0. You should be able to overcome this by installing the latest (1.4.0) winrm gem.
I have upgraded to winrm to 1.4 but still I am facing the same issue.
Just to confirm the newer gem is actually loading, does the stack trace now have the path to the 1.4 gem or is it still 1.3.4?
It is still bootstrapping with winrm 1.3.4 but when I execute
chef gem list it is showing winrm 1.4 ,1.3.4
Do I need to make any modifications to let it use only winrm 1.4
or shall I need to uninstall winrm 1.3.4 gem
go ahead and uninstall 1.3.4.
Still it is using the same gem and it is installing the chef-client partially on the node
As an aside, please be sure to change your password. It’s easy to forget to redact the password in command lines like this, but now that it showed up on this list, it should be considered compromised.
Kevin Keane
The NetTech
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
might try both gem uninstall winrm -v 1.3.4 and chef gem uninstall -v 1.3.4
I have uninstalled both but still there is no progress.
Is it the same error invalid byte sequence and does the stacktrace indicate winrm 1.4.0 is active?
In chef gem list it is showing 1.4 and 1.3.6 and I am getting the same error
ok thanks. I just did some investigation and it looks like this is an issue with the winrm-s gem which monkey patches winrm to provide negotiate auth on “windows to windows” bootstraps. The same fix applied to winrm 1.3.5 which strips the BOM injected by windows 2008R2 nodes needs to be applied in winrm-s. I’ll focus on releasing a fix there early next week.
I’m assuming you are trying to bootstrap windows 2008R2 or win 7 or older which is where we discovered the original encoding bug with winrm.
In the meantime you can work around this by either:
- using SSL
- using basic authentication.(strongly discouraged for production nodes)
- revert to winrm (v1.3.3)
I would suggest the latter route since it is the simplest. The encoding change to UTF-8 in 1.3.4 only benefits newer windows OS versions - namely Windows nano.
I apologize for the hassle involved here.
Hi Matt_Wrock, No need to say apologize and I should thank you for your support and I have already gone through the error that you have mentioned above about winrm-s monkey patch and found that the issue got closed and tried some stuff from there. Anyway thanks for the support.