Bug #16056
closed
Non-english locale casuses "Vendor Class not found" errors when using windows dhcp provider
Description
Good morning,
iam Setting up a new Foreman/Puppet infrastructure for provisioning VM's on VMware.
For this i need a DHCP Foreman-Proxy. I set up a new Forman-Proxy with following Details:
- Windows Server 2012 R2
- Foreman-Proxy stable Version 1.11.4
- netsh commands available and the DHCP Administrator Account is running the Foreman-Proxy-Service
The Foreman-Proxy is communicating with a DHCP Server based in Windows Server 2008.
The smart-Proxy.log said:
D, [2016-08-11T09:07:03.973132 #2532] DEBUG -- : executing: c:\windows\system32\cmd.exe /c c:\Windows\System32\netsh.exe -c dhcp server x.x.x.x show scope I, [2016-08-11T09:07:06.379463 #2532] INFO -- : Vendor class not found E, [2016-08-11T09:07:06.379463 #2532] ERROR -- : Netsh failed: Der folgende Befehl wurde nicht gefunden: server x.x.x.x show scope. E, [2016-08-11T09:07:06.379463 #2532] ERROR -- : Unknown error while processing 'Failed to enumerate the scopes on x.x.x.x Vendor class not found' D, [2016-08-11T09:07:06.379463 #2532] DEBUG -- : Unknown error while processing 'Failed to enumerate the scopes on x.x.x.x Vendor class not found' (Proxy::DHCP::Error) C:/smart-proxy-1.11-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:247:in `rescue in report' C:/smart-proxy-1.11-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:224:in `report' C:/smart-proxy-1.11-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:219:in `execute' C:/smart-proxy-1.11-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:182:in `find_all_subnets' C:/smart-proxy-1.11-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:195:in `load_subnets' C:/smart-proxy-1.11-stable/modules/dhcp/dhcp_api.rb:13:in `block in <class:DhcpApi>' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1611:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1611:in `block in compile!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1015:in `block in process_route' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in `catch' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1013:in `process_route' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:966:in `block in filter!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:966:in `each' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:966:in `filter!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1084:in `block in dispatch!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in `block in invoke' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in `catch' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in `invoke' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1082:in `dispatch!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:907:in `block in call!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in `block in invoke' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in `catch' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1067:in `invoke' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:907:in `call!' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:895:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/methodoverride.rb:21:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/commonlogger.rb:33:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:219:in `call' C:/smart-proxy-1.11-stable/lib/proxy/log.rb:60:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/nulllogger.rb:9:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/head.rb:11:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/show_exceptions.rb:25:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:182:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:2013:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1487:in `block in call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1787:in `synchronize' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/sinatra-1.4.7/lib/sinatra/base.rb:1487:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:138:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/urlmap.rb:65:in `block in call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/urlmap.rb:50:in `each' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/urlmap.rb:50:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/builder.rb:138:in `call' C:/Ruby23-x64/lib/ruby/gems/2.3.0/gems/rack-1.5.5/lib/rack/handler/webrick.rb:60:in `service' C:/Ruby23-x64/lib/ruby/2.3.0/webrick/httpserver.rb:140:in `service' C:/Ruby23-x64/lib/ruby/2.3.0/webrick/httpserver.rb:96:in `run' C:/Ruby23-x64/lib/ruby/2.3.0/webrick/server.rb:296:in `block in start_thread'
It seems it is a known Bug Comes if the DHCP Server is based on Windows Server 2008. I read this here (last Entry):
http://projects.theforeman.org/projects/foreman/wiki/ERF12-6899
There is also a Workaround for this, but it seems its for an old Smart-Proxy Version (ok - the post is three years old :) ) ...
I dont have the file dhcp.rb in path lib/proxy/dhcp.rb. This file is in my /module/dhcp path and the file is empty (just first "require 'dhcp/dhcp_plugin".
Did anyone know a Workaround for Smart-Proxy Version 1.11.4 ? ( i have this bug in 11.13 also .. :) ) - seems always been there and not Version specific.
Thanks for your Support.
Best Regards
Updated by Dominic Cleal over 8 years ago
- Is duplicate of Bug #13575: Don't fail due to missing PXEClient DHCP opt on 2008R2 added
Updated by Dominic Cleal over 8 years ago
- Status changed from New to Duplicate
This has been fixed via ticket #13575, please try version 1.12.1.
Updated by Anonymous over 8 years ago
Dominic Cleal wrote:
This has been fixed via ticket #13575, please try version 1.12.1.
Thanks for your fast reply. Iam sorry it still does not work.
I installed the whole VM with the Proxy Server 1.12.1 again. I still get the same error Message in the smart-proxy.log
E, [2016-08-11T11:05:46.673799 #2136] ERROR -- : Unknown error while processing 'Failed to enumerate the scopes on x.x.x.xVendor class not found' D, [2016-08-11T11:05:46.673799 #2136] DEBUG -- : Unknown error while processing 'Failed to enumerate the scopes on x.x.x.x Vendor class not found' (Proxy::DHCP::Error) C:/smart-proxy-1.12-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:251:in `rescue in report' C:/smart-proxy-1.12-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:228:in `report' C:/smart-proxy-1.12-stable/modules/dhcp_native_ms/dhcp_native_ms_main.rb:223:in `execute'
Thank you for your support.
Updated by Dominic Cleal over 8 years ago
- Is duplicate of deleted (Bug #13575: Don't fail due to missing PXEClient DHCP opt on 2008R2)
Updated by Dominic Cleal over 8 years ago
- Related to Bug #13575: Don't fail due to missing PXEClient DHCP opt on 2008R2 added
Updated by Anonymous over 8 years ago
- Tracker changed from Bug to Support
Could you try executing 'netsh.exe -c dhcp server <your server ip here> show scope' from the command line?
I suspect the issue is with your dhcp server, but I'm not sure what could cause it. Is it possible that you have options from a removed vendor class assigned to one or more subnets?
Updated by Anonymous over 8 years ago
Dmitri Dolguikh wrote:
Could you try executing 'netsh.exe -c dhcp server <your server ip here> show scope' from the command line?
I suspect the issue is with your dhcp server, but I'm not sure what could cause it. Is it possible that you have options from a removed vendor class assigned to one or more subnets?
Thanks for your reply. Yes its:
netsh.exe -c dhcp server x.x.x.x show scope ============================================================================== Bereichsadresse - Subnetzmaske - Status - Bereichsname - Kommentar ============================================================================== x.x.x.x - x.x.x.x -Aktiv -DHCP xxxx -xxx x.x.x.x - .x.x.x.x -xxx -xxx Gesamtanzahl der Bereiche = 2 Der Befehl wurde erfolgreich ausgeführt.
Sorry the server is in german language.
It said, the command is succed and the adresse details are right.
What do you meen with 'options from a removed vendor class assigned to one or more subnets' ? Is this something i can check or asking the DHCP-Team? Iam not the DHCP Administrator and my knowledge is limited here.
Thanks for your support
Updated by Anonymous over 8 years ago
- Tracker changed from Support to Bug
- Project changed from Foreman to Smart Proxy
- Category deleted (
DHCP)
I didn't realise the shell was in German too. The version of ms dhcp provider you are using relies on parsing of netsh output to determine command status (among other things). Localised netsh messages result in errors, as the parser looks for english phrases.
You can switch the locale to one of the english ones and the error will go away. Alternatively, you can try using changes in https://github.com/theforeman/smart-proxy/pull/445, but they haven't been extensively tested yet.
Updated by Anonymous over 8 years ago
- Subject changed from AD DHCP and Windows Server 2008 : Vendor Class not found to Non-english locale casuses "Vendor Class not found" errors when using windows dhcp provider
Updated by Anonymous over 8 years ago
Dmitri Dolguikh wrote:
I didn't realise the shell was in German too. The version of ms dhcp provider you are using relies on parsing of netsh output to determine command status (among other things). Localised netsh messages result in errors, as the parser looks for english phrases.
You can switch the locale to one of the english ones and the error will go away. Alternatively, you can try using changes in https://github.com/theforeman/smart-proxy/pull/445, but they haven't been extensively tested yet.
Thanks for your reply. Its not so easy to change the current system language, so i have to create a new machine with the english .iso. That needs a little bit time, i will reply here when iam done.
best regards
Updated by Anonymous over 8 years ago
Hello Dmitri,
hello dominic,
i set up the smart-proxy with 1.12.1 and windows server 2012 R2 in english. The smart-proxy works now. Everything works now as you said. Thanks for your support.
best regards
Updated by Anonymous over 8 years ago
- Related to Bug #7766: ms_native dhcp smart proxy code scales poorly added
Updated by Anonymous about 8 years ago
- Status changed from New to Closed
http://projects.theforeman.org/issues/7766 which resolves this issue has now been merged. I'm closing this ticket.