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?
--
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 [email protected].
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.
