Puppet/Facter custom fact on windows misbahaving

[Fredrik Nilsson]

Hi folks,

So I have an interesting behaviour of a custom fact I'm trying to deploy to our windows boxes using Puppet. I'm not certain wether this is a bug or if I'm doing the fact all wrong. I've been going over the fact it self a few times to make certain that it works as intended, and it seemingly do, so there must be something else going on. What I want to accomplish is to check which version of IIS is installed on the boxes that have that feature installed, the way I found to do that is to read the registry value found under the property "VersionString" under "HKLM:\SOFTWARE\Microsoft\InetStp". This fact will serve to purposes check wether IIS feature is installed and which version that is, of course one could settle just for checking if the feature is installed, but me myself never remember what version of IIS came with what version of Windows...

So this is my fact written in Ruby:

 Facter.add(:iis_version) do
  confine :kernel => :windows
  setcode do
 version = nil
 require 'win32/registry'
 begin
 Win32::Registry::HKEY_LOCAL_MACHINE.open('SOFTWARE\Microsoft\InetStp') do |reg|
 version = reg['VersionString']
  version = version[8,3]
 end
rescue Win32::Registry::Error
end
version
end
end

I've made some runs just using Ruby with a script from line 4-13 and then I wrapped it up in a facter wrapping and have "beta tested" it on some boxes manually putting the fact in this path: C:\ProgramData\PuppetLabs\puppet\var\lib\facter, everything working just great. If there is an IIS installation it returns the value of the registry property, and if that property is absent nothing is returned.

Then Puppet comes in to play, in my module I put my script in the path /lib/facter allong with my other customfacts (all the other are wrapped Powershell scripts), I run it through code review and such, Jenkins thinks everything is play ball. But then the fishy part comes in to play, as I said, obviously I've done a few itterations of the script to get it right and as I've come to understand the custom facts part in different modules, the /lib/facter path, could have problem with compartmentalization in our Puppet version (3.8.4). BTW our Windows boxes also on client version 3.8.4. Any way what happens is that on each puppet run the custom fact file, iis_version.rb, gets replaced two times, always with the same to hashes from {md5}11c0899297882d8c4b1e6005688a339a' to '{md5}8b99d355199c9628c459c6d7dc62e4ee' and then the step after back again :-S. When I check the content of the file I get this:

# iis_version.rb
Facter.add("iis_version") do
 confine :kernel => :windows
  setcode do
    begin
      psexec = if File.exists?("#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe")
                 "#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe"
               elsif File.exists?("#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe")
                "#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe"
               else
                'powershell.exe'
               end
      iis_ver = %x{#{psexec} -ExecutionPolicy ByPass -Command "(Get-ItemProperty HKLM:\\SOFTWARE\\Microsoft\\InetStp\\ -Name VersionString).VersionString.SubString(8,3)"}
    rescue
      iis_ver = ""
    end
    iis_ver
  end
end

SAY WHAAAAAT? It is a not entirely satisfying "translation" of my Ruby script into a wrapped Powershell script, it misses out on some key parts from my point of view. This have happened all the time since the first itteration of my script, which I think never have been a wrapped script, it have always been all Ruby, don't quite recall though.

I have no clue where this is comming from.  I think my Ruby script is just fine, it's my first one so it might look ugly to a Ruby jedi. But neither me (a Windows admin) or the puppet master (a Linux guy) can figure this one out. Anyone have a clue, seen the same behaviour, have any pointers?

[Peter Huene]

It looks like another module has a custom fact with the same file name.  Unfortunately Puppet agent's pluginsync doesn't properly handle modules with identical file names very well.

Does renaming your fact file to something unique work?  If so, that would indicate the issue is a conflict with another module's file and the other module is unfortunately overwriting your fact when the custom facts are synced to the agent.

 

I have no clue where this is comming from.  I think my Ruby script is just fine, it's my first one so it might look ugly to a Ruby jedi. But neither me (a Windows admin) or the puppet master (a Linux guy) can figure this one out. Anyone have a clue, seen the same behaviour, have any pointers?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c16d6904-25e1-4cba-8cab-5d8d7f9dba84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fredrik Nilsson]

That is actually one path me and the puppet master have been discussing to walk down. Either renaming my custom fact to something else then the now present fact, to see what's happening. Or to remove the present "issue" fact from the module to see if it persists or so to say clean out any ghosts in the system. I'll have a go at that and see if it solves the matter or not.

It's fishy though as the fact it self is faulty as it populates the fact value with an error message if it fails to retrieve the registry value, and am the only one who would be the author of a Windows fact in our puppet environment. Anyhow, going back to the testing bench trying the above to see what happens...