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

On Wednesday, 18 November 2015 17:59:21 UTC+1, Peter Huene wrote:
>
> On Wed, Nov 18, 2015 at 1:54 AM, Fredrik Nilsson <[email protected] 
> <javascript:>> wrote:
>
>> 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.
>>
>
> 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 [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/c16d6904-25e1-4cba-8cab-5d8d7f9dba84%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/c16d6904-25e1-4cba-8cab-5d8d7f9dba84%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/96535841-e858-4bf8-a798-81991ce2d479%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to