Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

windows_certificate create action does not appear to be idempotent #296

Closed
chrisgit opened this issue Nov 16, 2015 · 9 comments · Fixed by #302
Closed

windows_certificate create action does not appear to be idempotent #296

chrisgit opened this issue Nov 16, 2015 · 9 comments · Fixed by #302

Comments

@chrisgit
Copy link

Converging on a Windows 2012 RTM virtual box the windows_certificate resource always runs irrespective of whether the certificate is installed in the certificate store.

Example usage of the windows_certificate resource

  windows_certificate "C:/certs/my_cert_file" do
    pfx_password 'my_password'
  end  

Having looked at the code I think the powershell resource used in the create method needs changing to specify the guard interpreter

  powershell_script new_resource.name do
    guard_interpreter :powershell_script
    code code_script
    not_if guard_script
  end

Alternatively if a guard_interpreter is not specified the resource can be made idempotent by returning an exit code of 0 or 1 from the script by changing it to

def cert_exists_script(hash)
  <<-EOH
$hash = #{hash}
If ((Test-Path "Cert:\\#{@location}\\#{new_resource.store_name}\\$hash") -eq $true) {exit 0} else {exit 1}
EOH
end

Both solutions above tested with Chef 11.18.6 and 12.4.1.

@mwrock
Copy link
Contributor

mwrock commented Nov 17, 2015

The default guard_interpreter for powershell_script is powershell. I sanity checked this running the certificate recipe in the minimal test cookbook included with this repo and the certificate create was idempotrent.

Could you provide debug output of a non idempotent run?

@chrisgit
Copy link
Author

Hi Matt, thank you very much for taking the time and trouble to look into this issue, it is very much appreciated, even just for the sanity check.

My understanding is that the default guard interpreter for a powershell_script resource was powershell which is why I'm perplexed.

It was our managed Chef server that alerted us to the fact that the resource does not appear to be idempotent as it appears in the run report after every run
chef_node_converge_edit

At first I thought that it might be an issue with the updated_by_last_action not being set correctly but it definitely appears to be an issue with the guard.

Here is the debug output from running the resource.

chef_node_converge.txt

Running the guard code directly in PowerShell returns True
chef_node_cert_guard

@mwrock
Copy link
Contributor

mwrock commented Nov 17, 2015

What version of chef client is your node running? 11.18.6? I'll see if I can reproduce there today.

@chrisgit
Copy link
Author

The converge this morning was with Chef client 12.4.1. Thank you

@mwrock
Copy link
Contributor

mwrock commented Nov 17, 2015

Oh OK. Good to know.

@chrisgit
Copy link
Author

Matt, sorry I was incorrect, the windows_certificate does not appear to be idempotent in Chef client 11.18.6 but does appear to work perfectly well in Chef client 12.4.1, I assume because of the wrapper code that the Chef client adds to PowerShell script (as seen in the debug output).

Please accept my apologies, I'll understand if you want to close the issue due to us using an outdated Chef client.

@mwrock
Copy link
Contributor

mwrock commented Nov 17, 2015

Hey no problem at all. We'd certainly like this to be backward compatible to v11 so thanks a bunch for the update and I will test there.

@chrisgit
Copy link
Author

Tested the v1.38.4 release of the windows cookbook. windows_certificate is idempotent in Chef 11. Thank you.

@mwrock
Copy link
Contributor

mwrock commented Nov 18, 2015

Ah great to hear!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

2 participants