The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Bug #12980
Puppet::Util.execute on Windows should search 64-bit path first
| Status: | Accepted | Start date: | 03/06/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Josh Cooper | % Done: | 0% | |
| Category: | windows | |||
| Target version: | - | |||
| Affected Puppet version: | 2.7.6 | Branch: | ||
| Keywords: | windows, 32bit, 64bit, redirection, syswow64 | |||
We've Moved!Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com |
||||
Description
Because ruby is a 32bit process, it searches 32bit path first, which unfortunately is typically the wrong binary on 64bit servers:
"You cannot service a running 64-bit operating system with a 32-bit version of DISM.
Please use the version of DISM that corresponds to your computer's architecture."
Related issues
History
#1
Updated by Nan Liu about 4 years ago
Here’s the work around: http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx
%windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access
#2
Updated by Josh Cooper about 4 years ago
- Category set to windows
- Status changed from Unreviewed to Accepted
- Assignee set to Josh Cooper
- Target version set to 2.7.x
- Affected Puppet version set to 2.7.6
Puppet should provide a method that given a path will see if the sysnative version of it exists, and if so, use that. Otherwise, fallback to system32. For example, the exec provider on windows should call that to resolve the windows system path for 64-bit versions of cmd.exe, powershell.exe, etc.
#3
Updated by Nan Liu about 4 years ago
We have additional issues when invoking regedit through puppet command line:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724072(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx
#4
Updated by Josh Cooper almost 4 years ago
Reminder to myself to update facter too, see #13678, and https://github.com/puppetlabs/facter/commit/ec0e80b9e79673ce5dc61a9eeb0f11d95a5ed2a2
#5
Updated by Josh Cooper almost 4 years ago
- Keywords changed from windows, 32bit, 64bit to windows, 32bit, 64bit, redirection, syswow64
Fixing this is going to be harder than it should be. Puppet validates the exec resource’s command using Puppet::Util.which based on the resource[:path]. Puppet then executes the command using the unqualified form (essentially throwing away the result of the which command). This is fine on POSIX, because when executing an exec:
If the file argument contains a slash character, the file argument shall be used as the pathname for this file. Otherwise, the path prefix for this file is obtained by a search of the directories passed as the environment variable PATH
In other words, exec just turns around and re-does what which did.
But on Windows, the call to CreateProcess looks in various directories before using the PATH environment variable, such as the current directory, current directory of the parent process, the SYSWOW64 directory, etc. So I think the Windows exec provider should be modified to always execute using the fully qualified path as returned by which.
#6
Updated by Josh Cooper almost 4 years ago
swolf brought up the point that there are times when you really do want the 32-bit version of powershell http://www.puppetlogs.com/puppet/%23puppet-2012-06-14.log.html
[2012/06/14 18:20:16]jmccune: yessir. and give pk access to user accounts, and perhaps even netsh commands to attach to url [2012/06/14 18:20:24] like this: http://msdn.microsoft.com/en-us/library/ms733791.aspx [2012/06/14 18:21:40] import pfx is something like this [2012/06/14 18:21:41] http://www.orcsweb.com/blog/james/powershell-ing-on-windows-server-how-to-import-certificates-using-powershell/
I think we do want to prefer 64-bit executables when an relative path is specified, but still be able to execute 32-bit code via absolute path:
$path = "#{ENV['SYSTEMROOT']}\\system32\\powershell.exe"
#7
Updated by Josh Cooper almost 4 years ago
- Subject changed from Puppet on Windows execute search 32bit path first to Puppet::Util.execute on Windows should search 64-bit path first
#8
Updated by Josh Cooper over 3 years ago
We’ve documented Windows filesystem redirection behavior http://docs.puppetlabs.com/windows/running.html#file-system-redirection-in-64-bit-windows-versions, but a lot of people on the mailing list have run into this issue:
https://groups.google.com/forum/#!msg/puppet-users/A_9i2Wx1yFI/ZUxK5U-yWZYJ
https://groups.google.com/forum/#!msg/puppet-users/sva-_CmZHdg/jTWLC6Vz4FQJ
https://groups.google.com/forum/#!msg/puppet-users/gAWFc7fiLyE/cqynD9TtAR4J
Perhaps we should add a warning when accessing files (exec or file resource) in c:\windows\system32 and running on 64-bit OS?
We can’t disable filesystem redirection for the ruby process, because it would interfere with DLL loading, etc.
#9 Updated by Anonymous over 3 years ago
- Target version deleted (
2.7.x)
#10
Updated by Luis Mayorga about 3 years ago
Hi,
I am using the Windows Enterprise Version for testing on Windows 2008 R2. My findings so far.
- It works by using the following command:
exec{'dism':
command => 'c:\windows\sysnative\dism.exe /online /enable-feature /featurename:IIS-WebServerRole /featurename:IIS-WebServerManagementTools /featurename:IIS-ManagementConsole',
logoutput=> true
}
- It doesn’t work when using the path attribute:
exec{'dism':
path => 'c:\windows\sysnative',
command => 'dism.exe /online /enable-feature /featurename:IIS-WebServerRole /featurename:IIS-WebServerManagementTools /featurename:IIS-ManagementConsole',
logoutput=> true
}
#11
Updated by Josh Cooper about 3 years ago
Luis Mayorga wrote:
- It doesn’t work when using the path attribute:
exec{'dism': path => 'c:\windows\sysnative', command => 'dism.exe /online /enable-feature /featurename:IIS-WebServerRole /featurename:IIS-WebServerManagementTools /featurename:IIS-ManagementConsole', logoutput=> true }
That needs to be path => "c:\\windows\\sysnative;$::path".