[chef] RE: Oddity with not_ifs on Windows


Chronological Thread 
  • From: Adam Edwards < >
  • To:
  • Subject: [chef] RE: Oddity with not_ifs on Windows
  • Date: Sat, 31 May 2014 07:47:40 -0700

I see two issues below:

 

1.       You might try including –scope in your get-executionpolicy – I remember hitting issues without that, and all my cookbooks include this for a very similar scenario

2.       I believe the not_if for your 64-bit _expression_ will always run a 32-bit cmd.exe (and powershell.exe) and thus give you a 32-bit answer. You can try using “sysnative” instead of ‘system32’ to get around this (sysnative is doc’d on msdn).

 

However, I can also think of some other ways to do this – if you’re using  Chef 11.12 or later, you can use the guard_interpreter attribute (http://docs.opscode.com/resource_common.html)  to write a simpler _expression_ – this one sets 64-bit execution policy to remotesigned:

 

powershell_script "set execution policy" do

  guard_interpreter :powershell_script

  code "set-executionpolicy -scope localmachine remotesigned"

  not_if "(get-executionpolicy -scope localmachine) -eq 'remotesigned'"

end

 

The above would handle it for x64, just add architecture to do it for x86 (aka i386) – the guard inherits the i386-ness:

 

powershell_script "set execution policy" do

  guard_interpreter :powershell_script

  architecture :i386

  code "set-executionpolicy -scope localmachine remotesigned"

  not_if "(get-executionpolicy -scope localmachine) -eq 'remotesigned'"

end

 

You can do similar things prior to 11.12 and use the architecture attribute, but without guard_interpreter, you have to write more complicated expressions for the guard since the guard will always execute a 64-bit process. Guard_interpreter also does some magic to make boolean expressions in PowerShell into process exit codes that work as guards, similar to what you can do with the test ( aka [] ) in Unix shells with guards (described in convert_boolean_return attribute in http://docs.opscode.com/release_notes.html).

 

-Adam

 

From: Tim Smith [mailto: "> ]
Sent: Friday, May 30, 2014 5:21 PM
To: ">
Subject: [chef] Oddity with not_ifs on Windows

 

I’m noticing a really odd behavior with not_if statements on Windows and I was curious if anyone else had run into a similar situation.  I’m trying to set powershell execution policy to unrestricted with Chef using the following resources:

 

execute 'set 64bit powershell execution to unrestricted' do

  command '%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force'

  action :run

  not_if { `%SystemRoot%\\system32\\WindowsPowerShell\\v1.0\\powershell.exe Get-ExecutionPolicy`.include?('Unrestricted') }

end

 

execute 'set 32bit powershell execution to unrestricted' do

  command '%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy Unrestricted -Scope LocalMachine -Force'

  action :run

  not_if { `%SystemRoot%\\syswow64\\WindowsPowerShell\\v1.0\\powershell.exe Get-ExecutionPolicy`.include?('Unrestricted') }

end

 

The trouble is the resources are always skipped.  If I run the following from cmd as the Administrator I get back ‘restricted’ as expected:

%SystemRoot%\\system32\\WindowsPowerShell\\v1.0\\powershell.exe Get-ExecutionPolicy

Restricted

 

If I fire up IRB I get a completely different answer:

 

irb(main):019:0> `%SystemRoot%\\system32\\WindowsPowerShell\\v1.0\\powershell.exe Get-ExecutionPolicy`

=> "Unrestricted\n”

 

I noticed that if I echo the architecture in IRB I get 32bit, while I get 64bit back from the command prompt.  It seems like I should still back the correct answer since I’m trying to execute against 32bit powershell, but clearly something is wrong here.  Any advice?

 

-Tim

 

 

The information in this message may be confidential.  It is intended solely for

the addressee(s).  If you are not the intended recipient, any disclosure,

copying or distribution of the message, or any action or omission taken by you

in reliance on it, is prohibited and may be unlawful.  Please immediately

contact the sender if you have received this message in error.

 




Archive powered by MHonArc 2.6.16.

§