The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using 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

Added by Nan Liu about 4 years ago. Updated about 3 years ago.

Status:AcceptedStart date:03/06/2012
Priority:NormalDue 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

Related to Facter - Refactor #13678: Facter should implement its own which command Closed 04/06/2012
Related to Puppet - Bug #16019: Don't add /usr/sbin and /sbin to puppet's path on Windows Closed 08/17/2012
Related to Puppet - Bug #17603: Puppet execute has unexpected semantics Accepted
Related to Puppet - Feature #21666: Support ruby x64 on windows Accepted
Duplicated by Puppet - Feature #13198: Provide common way of handling filesystem redirection on ... Duplicate 03/16/2012

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

#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.

  1. 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 }

  1. 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:

  1. 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".

Also available in: Atom PDF