Re: [Puppet Users] Example of how to use require with hiera?

[Rich Burroughs]

I'm not clear what the context is here. Those snippets are what's in your
YAML file? Maybe you could post the relevant code from your manifest too?


Rich

On Thu, Sep 18, 2014 at 6:19 PM, Daniel Johnson  wrote:

> Things like
>
> require: File['somefile']
>
> or
>
> require:
>   File: somefile
>
> both crash, and burn.
>
> Not having a require also causes failure as it tries to do things it
> can't without the prerequisite.
>
> After hours of searching I couldn't find any examples to work from.
>
> --
> teknotus (Take Notice)
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CA%2BnDE0gpiOywMoEth4OJSG-aYOOB%2BZ17LOy1_YhQ6u8L5NiAcw%40mail.gmail.com
> .
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAPGcbtCMfWty6c_pHVpv_s2mh0g2cxihvzjjWN1xAosMuDhvHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Locally Written Puppet Module Does Not Dislay Version Number With: puppet module list

[Allen Santora]

Greetings,

(puppet-server-3.5.1 on CentOS 6.4)

I'm writing my own nodejs manager in Puppet and I want to enforce a version 
number

I have generated the module skeleton with the command: # puppet module 
generate company-nodejs
in /etc/puppet/modules

I then created /etc/puppet/modules/company-nodejs/metadata,json with the
basic content found at the URL:

https://docs.puppetlabs.com/puppet/latest/reference/modules_publishing.html#write-a-metadatajson-file

(... with appropriate local edits to metadata.json including...

"version": "0.0.1",

)

I then check the module with the command below but I am not getting a 
version number

#  puppet module list | grep node

company-nodejs (???)

Does anyone know why I am not getting a version number?

Thanks in advance.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3655002c-3caf-49f6-8ef2-491cad1f88ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Unable to do "puppet apply nodes.pp"

[Jürgen Hermann]

 The Puppet file you pass to an apply is basically a full site.pp, so try 
adding a "node default {…}" around your resources.

See https://github.com/jhermann/devpi-puppet/blob/master/site.pp#L31 for an 
example.

 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/eebcf61f-5e52-4829-8004-3b4d4ea876cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Example of how to use require with hiera?

[Daniel Johnson]

Things like

require: File['somefile']

or

require:
  File: somefile

both crash, and burn.

Not having a require also causes failure as it tries to do things it
can't without the prerequisite.

After hours of searching I couldn't find any examples to work from.

-- 
teknotus (Take Notice)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2BnDE0gpiOywMoEth4OJSG-aYOOB%2BZ17LOy1_YhQ6u8L5NiAcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Using Powershell in facters yields no data

[Brian Morris]

Thank you for that, Josh, as well as for creating the Powershell module for
Puppet. I hope to meet both you and Rob at PuppetConf next week.

On Thu, Sep 18, 2014 at 4:24 PM, Josh Cooper  wrote:

>
>
> On Thu, Sep 18, 2014 at 2:17 PM, Brian Morris 
> wrote:
>
>> Holy cow, Rob... that was great info! All I did was change "System32" to
>> "sysnative", and it worked on the first try. All of that frustration boiled
>> down to one part of one path...
>>
>> Thank you for the link, too. It helps to understand why this happens.
>> Cheers to you!
>>
>
> I filed https://tickets.puppetlabs.com/browse/FACT-710. as facter should
> use 64-bit powershell when available.
>
>
>> On Thu, Sep 18, 2014 at 1:59 PM, Rob Reynolds  wrote:
>>
>>>
>>>
>>> On Thu, Sep 18, 2014 at 3:54 PM, Rob Reynolds 
>>> wrote:
>>>


 On Thu, Sep 18, 2014 at 2:11 PM, Brian Morris <
 nomadicextre...@gmail.com> wrote:

> Hello all,
>
> I have been banging my head against this one for a couple of days. I
> am trying to use Powershell to comb the Windows registry for installed
> applications, such as VMware Tools, to create a custom facter. If I run
> this code from a PS prompt it works, and returns the expected data:
>
> PS C:\> Get-ChildItem
> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
> {Get-ItemProperty $_.ps
> path} | Where-Object {$_.DisplayName -eq "VMware Tools"} |
> ForEach-Object -process {$_.DisplayVersion }
> *9.4.6.1770165*
>
>
 This is running in a 64bit process.



> However, running the same thing through Puppet as a facter yields zero
> data:
>
> --
> Facter.add("vmtools_version") do
> confine :osfamily => "Windows"
>   setcode do
> 
> Facter::Util::Resolution.exec('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
> -Command
>

>>> C:\Windows\System32 is also subject to File system redirection, which is
>>> also talked about in that post. Likely fixing only this as sysnative will
>>> return the right data because PowerShell will run in 64bit mode. But I
>>> would explore the ruby only way to speed up the fact.
>>>
>>>
 "& {Get-ChildItem
> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
> {Get-ItemProperty $_.pspath} | Where-Object {$_.DisplayName -eq \"VMware
> Tools\"} | ForEach-Object -process {$_.DisplayVersion } } "')
> end
> end
> --
>

 This is in a 32bit process unless you are on the newest 3.7.0 or 3.7.1
 x64 builds of Puppet. You are hitting registry redirection.  Be sure to
 checkout Common Gotchas[1] especially for how to turn off registry
 redirection in a 32 bit process.


 [1] http://puppetlabs.com/blog/how-avoid-common-windows-gotchas-puppet


 More detail:

 When a 32 bit process calls the registry and is subject to redirection,
 it only sees the Wow6432Node under software. Check out that link above, it
 explains quite a bit in more detail.



>
> The left side shows up in the facters as "vmtools_version", but the
> right side is always empty. I have tried using the  GetItem module 
> instead,
> and tried various combinations of the "-Command" switch, removed the
> "For-Each" handler to see if would spit out a huge block of text, and even
> tried wrapping the whole thing in a "try & catch" to see if any error
> states are generated, but have never gotten any right side output at all.
>
> Does anyone have an idea that might make this work?
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/a76b897f-9f1f-4e82-ab18-344ae9a6e2c7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Rob Reynolds
 Developer, Puppet Labs

 *Join us at PuppetConf 2014 , September
 20-24 in San Francisco*

>>>
>>>
>>>
>>> --
>>> Rob Reynolds
>>> Developer, Puppet Labs
>>>
>>> *Join us at PuppetConf 2014 , September
>>> 20-24 in San Francisco*
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Puppet Users" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/puppet-users/8m8mt4G_OKU/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> puppet-users+unsubscr...@g

Re: [Puppet Users] Using Powershell in facters yields no data

[Josh Cooper]

On Thu, Sep 18, 2014 at 2:17 PM, Brian Morris 
wrote:

> Holy cow, Rob... that was great info! All I did was change "System32" to
> "sysnative", and it worked on the first try. All of that frustration boiled
> down to one part of one path...
>
> Thank you for the link, too. It helps to understand why this happens.
> Cheers to you!
>

I filed https://tickets.puppetlabs.com/browse/FACT-710. as facter should
use 64-bit powershell when available.


> On Thu, Sep 18, 2014 at 1:59 PM, Rob Reynolds  wrote:
>
>>
>>
>> On Thu, Sep 18, 2014 at 3:54 PM, Rob Reynolds  wrote:
>>
>>>
>>>
>>> On Thu, Sep 18, 2014 at 2:11 PM, Brian Morris >> > wrote:
>>>
 Hello all,

 I have been banging my head against this one for a couple of days. I am
 trying to use Powershell to comb the Windows registry for installed
 applications, such as VMware Tools, to create a custom facter. If I run
 this code from a PS prompt it works, and returns the expected data:

 PS C:\> Get-ChildItem
 hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
 {Get-ItemProperty $_.ps
 path} | Where-Object {$_.DisplayName -eq "VMware Tools"} |
 ForEach-Object -process {$_.DisplayVersion }
 *9.4.6.1770165*


>>> This is running in a 64bit process.
>>>
>>>
>>>
 However, running the same thing through Puppet as a facter yields zero
 data:

 --
 Facter.add("vmtools_version") do
 confine :osfamily => "Windows"
   setcode do
 
 Facter::Util::Resolution.exec('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
 -Command

>>>
>> C:\Windows\System32 is also subject to File system redirection, which is
>> also talked about in that post. Likely fixing only this as sysnative will
>> return the right data because PowerShell will run in 64bit mode. But I
>> would explore the ruby only way to speed up the fact.
>>
>>
>>> "& {Get-ChildItem
 hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
 {Get-ItemProperty $_.pspath} | Where-Object {$_.DisplayName -eq \"VMware
 Tools\"} | ForEach-Object -process {$_.DisplayVersion } } "')
 end
 end
 --

>>>
>>> This is in a 32bit process unless you are on the newest 3.7.0 or 3.7.1
>>> x64 builds of Puppet. You are hitting registry redirection.  Be sure to
>>> checkout Common Gotchas[1] especially for how to turn off registry
>>> redirection in a 32 bit process.
>>>
>>>
>>> [1] http://puppetlabs.com/blog/how-avoid-common-windows-gotchas-puppet
>>>
>>>
>>> More detail:
>>>
>>> When a 32 bit process calls the registry and is subject to redirection,
>>> it only sees the Wow6432Node under software. Check out that link above, it
>>> explains quite a bit in more detail.
>>>
>>>
>>>

 The left side shows up in the facters as "vmtools_version", but the
 right side is always empty. I have tried using the  GetItem module instead,
 and tried various combinations of the "-Command" switch, removed the
 "For-Each" handler to see if would spit out a huge block of text, and even
 tried wrapping the whole thing in a "try & catch" to see if any error
 states are generated, but have never gotten any right side output at all.

 Does anyone have an idea that might make this work?

 --
 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+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/puppet-users/a76b897f-9f1f-4e82-ab18-344ae9a6e2c7%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> Rob Reynolds
>>> Developer, Puppet Labs
>>>
>>> *Join us at PuppetConf 2014 , September
>>> 20-24 in San Francisco*
>>>
>>
>>
>>
>> --
>> Rob Reynolds
>> Developer, Puppet Labs
>>
>> *Join us at PuppetConf 2014 , September
>> 20-24 in San Francisco*
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Puppet Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/puppet-users/8m8mt4G_OKU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/CAMJiBK7GNgWponY1y74bpQ5x_YPbRcPeK3%3DmsyBc-W2txDfQaQ%40mail.gmail.com
>> 
>> .
>>
>> For more options, visit https

Re: [Puppet Users] About the "params" pattern

[Francois Lafont]

Hi,

Le 18/09/2014 16:40, jcbollinger a écrit :

> Sorry, I worded that very poorly.

Really no problem. ;)

> Class my_module inherits my_module::params.  Absent my_module declaring its 
> own local variables $foo1 and $foo2, the inheritance results in variables 
> $::my_module::params::foo1 and $::my_module::params::foo2 being accessible 
> unqualified in class my_module's namespace.  Because those variables are 
> accessible unqualified in class my_module, they are also accessible 
> elsewhere qualified by namespace my_module (i.e. $::my_module::foo1) -- 
> *that* little bit of evil should not be used.  Instead, always qualify 
> variable references with the namespace in which the variable is actually 
> declared (my_module::params in this case).

Ok. Indeed I have read in Puppet documentation that it's better to avoid
unqualified variable (I have seen it's a "wolf trap") and it's better to
use fully qualified variable.

So, finally, is this way below a correct and good way to use the "params"
pattern?

-
# Example of declaration for the "test" class.
class { test:
  var1 => 'specific_var1',
}

 test module with its classes 
class test::params {
  # API
  $var1 = 'default_var1'
  $var2 = 'default_var2'

  # Shared variables
  $foo1 = 'value_foo1'
  $foo2 = 'value_foo2'
}

# The main class of the module

# I use fully qualified variable names exclusively!
class test (
  $var1 = $::test::params::var1,
  $var2 = $::test::params::var2,
) inherits test::params {

  include ::test::internal

  notify { 'v1': message => "var1 = $::test::var1", }
  notify { 'v2': message => "var2 = $::test::var2", }
  notify { 'f1': message => "foo1 = $::test::foo1", }
  notify { 'f2': message => "foo2 = $::test::foo2", }

}

class test::internal {

  notify { 'iv1': message => "Internal var1 = $::test::var1", }
  notify { 'iv2': message => "Internal var2 = $::test::var2", }
  notify { 'if1': message => "Internal foo1 = $::test::foo1", }
  notify { 'if2': message => "Internal foo2 = $::test::foo2", }

  # So, in templates, I use the syntax scope['::test::var']
  # (I'm using Puppet 3.7.1 so -> scope[...])
  file { '/temp/internal.txt':
content => inline_template("var1=<%= scope['::test::var1'] %>\nfoo2=<%= 
scope['::test::foo2'] %>\n"),
  }
}
-

I use $::test::xxx in class::internal not $::test::params::xxx
because when xxx is "var1" or "var2", I want to have the value of
var1 and var2 given as parameters of the test class (I don't want
the default value of var1 and var2).

Like this, it all seems to you correct?

> No, not in the slightest.  I mean that if class my_module::params has a 
> local variable with unqualified name "foo1", then that variable can be 
> referenced from any class in any module as $my_module::params::foo1, 
> regardless of any inheritance or include / require / contain statements 
> anywhere.  

Hum... there is exception, isn't? For instance, it depends of the
order of the class in the catalog, I'm wrong?

For instance, with this manifest:

-
include ::test1
include ::test2

class test1 {
  $var1 = "var1"
  notify { 'm1': message => "var2 = $::test2::var2", }
}

class test2 {
  $var2 = "var2"
  notify { 'm2': message => "var1 = $::test1::var1", }
}
-

I have this result:

~$ puppet apply manifest.pp 
Warning: Scope(Class[Test1]): Could not look up qualified variable 
'::test2::var2'; class ::test2 has not been evaluated
Notice: Compiled catalog for wheezy-clean.chezmoi.priv in environment 
production in 0.02 seconds
Notice: var1 = var1
Notice: /Stage[main]/Test2/Notify[m2]/message: defined 'message' as 'var1 = 
var1'
Notice: var2 = 
Notice: /Stage[main]/Test1/Notify[m1]/message: defined 'message' as 'var2 = '
Notice: Finished catalog run in 0.41 seconds

>> I can give you a precise and quick (if you have already a Debian Wheezy) 
>> process to reproduct this. I take a Debian Wheezy, updated and cleaned 
>> (it's a simple VM in Virtualbox). And here is the process: 
>>
>>
> 
> I'm not prepared to set up and run this test, 

Ok. Let me show you an even faster test than the previous test (no installation
of puppetmaster just the puppet agent) :

root@wheezy-clean:~# lsb_release -sc
wheezy

root@wheezy-clean:~# wget 
https://apt.puppetlabs.com/puppetlabs-release-$(lsb_release -sc).deb
root@wheezy-clean:~# dpkg -i puppetlabs-release-$(lsb_release -sc).deb
root@wheezy-clean:~# apt-get update
root@wheezy-clean:~# apt-get install puppet
root@wheezy-clean:~# puppet -V
3.7.1

# Just comment the "templatedir" line in puppet.conf (which is deprecated)
root@wheezy-clean:~# sed -i -r 's/^(templatedir.*)$/#\1/g' 
/etc/puppet/puppet.conf

# Create a simple manifest.
root@wheezy-clean:~# vim manifest.pp

Here is my (very) simple manifest:

--
include ::test

class test {
  $var

Re: [Puppet Users] puppetlabs-* forge modules and 'parser = future'

[Spencer Krum]

+1 for a plan for this

On Thu, Sep 18, 2014 at 2:16 PM, Tim Skirvin  wrote:

> I decided to try out 'parser = future' today, and the first thing
> to fail was puppetlabs-apache, with errors along the lines of:
>
> Filepath:
> /srv/puppet/env/puppet/modules/apache/templates/httpd.conf.erb
> Line: 19
> Detail: comparison of Float with String failed
>
> There's already a bug report for this[1], but that's not really
> my point.  I'm curious as to the larger questions - when are the modules
> supported by PuppetLabs in the Forge going to be ready for use with the
> future parser?  And, when these modules are ready, how will we know?  Will
> it be listed as compatible with 4.0.0?
>
> And until this is ready, is 'parser = future' doing much good?
>
> - Tim Skirvin (tskir...@fnal.gov)
> --
> HPC Systems Administrator / Developer
> http://www.linkedin.com/in/tskirvin
>USCMS-T1 Collaboration   Fermilab Scientific Computing
>
> [1] https://tickets.puppetlabs.com/browse/MODULES-910
>



-- 
Spencer Krum
(619)-980-7820

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CADt6FWOMjWQtszuwncC42Mgs%2BcBmuNF2tC8zyr%3DxdusXCObhFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetlabs-* forge modules and 'parser = future'

[Tim Skirvin]

I decided to try out 'parser = future' today, and the first thing
to fail was puppetlabs-apache, with errors along the lines of:

Filepath: /srv/puppet/env/puppet/modules/apache/templates/httpd.conf.erb
Line: 19
Detail: comparison of Float with String failed

There's already a bug report for this[1], but that's not really
my point.  I'm curious as to the larger questions - when are the modules
supported by PuppetLabs in the Forge going to be ready for use with the
future parser?  And, when these modules are ready, how will we know?  Will
it be listed as compatible with 4.0.0?

And until this is ready, is 'parser = future' doing much good?

- Tim Skirvin (tskir...@fnal.gov)
-- 
HPC Systems Administrator / Developerhttp://www.linkedin.com/in/tskirvin
   USCMS-T1 Collaboration   Fermilab Scientific Computing

[1] https://tickets.puppetlabs.com/browse/MODULES-910


pgpWGTj9jILu0.pgp
Description: PGP signature

Re: [Puppet Users] Using Powershell in facters yields no data

[Brian Morris]

Holy cow, Rob... that was great info! All I did was change "System32" to
"sysnative", and it worked on the first try. All of that frustration boiled
down to one part of one path...

Thank you for the link, too. It helps to understand why this happens.
Cheers to you!

On Thu, Sep 18, 2014 at 1:59 PM, Rob Reynolds  wrote:

>
>
> On Thu, Sep 18, 2014 at 3:54 PM, Rob Reynolds  wrote:
>
>>
>>
>> On Thu, Sep 18, 2014 at 2:11 PM, Brian Morris 
>> wrote:
>>
>>> Hello all,
>>>
>>> I have been banging my head against this one for a couple of days. I am
>>> trying to use Powershell to comb the Windows registry for installed
>>> applications, such as VMware Tools, to create a custom facter. If I run
>>> this code from a PS prompt it works, and returns the expected data:
>>>
>>> PS C:\> Get-ChildItem
>>> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
>>> {Get-ItemProperty $_.ps
>>> path} | Where-Object {$_.DisplayName -eq "VMware Tools"} |
>>> ForEach-Object -process {$_.DisplayVersion }
>>> *9.4.6.1770165*
>>>
>>>
>> This is running in a 64bit process.
>>
>>
>>
>>> However, running the same thing through Puppet as a facter yields zero
>>> data:
>>>
>>> --
>>> Facter.add("vmtools_version") do
>>> confine :osfamily => "Windows"
>>>   setcode do
>>> 
>>> Facter::Util::Resolution.exec('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
>>> -Command
>>>
>>
> C:\Windows\System32 is also subject to File system redirection, which is
> also talked about in that post. Likely fixing only this as sysnative will
> return the right data because PowerShell will run in 64bit mode. But I
> would explore the ruby only way to speed up the fact.
>
>
>> "& {Get-ChildItem
>>> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
>>> {Get-ItemProperty $_.pspath} | Where-Object {$_.DisplayName -eq \"VMware
>>> Tools\"} | ForEach-Object -process {$_.DisplayVersion } } "')
>>> end
>>> end
>>> --
>>>
>>
>> This is in a 32bit process unless you are on the newest 3.7.0 or 3.7.1
>> x64 builds of Puppet. You are hitting registry redirection.  Be sure to
>> checkout Common Gotchas[1] especially for how to turn off registry
>> redirection in a 32 bit process.
>>
>>
>> [1] http://puppetlabs.com/blog/how-avoid-common-windows-gotchas-puppet
>>
>>
>> More detail:
>>
>> When a 32 bit process calls the registry and is subject to redirection,
>> it only sees the Wow6432Node under software. Check out that link above, it
>> explains quite a bit in more detail.
>>
>>
>>
>>>
>>> The left side shows up in the facters as "vmtools_version", but the
>>> right side is always empty. I have tried using the  GetItem module instead,
>>> and tried various combinations of the "-Command" switch, removed the
>>> "For-Each" handler to see if would spit out a huge block of text, and even
>>> tried wrapping the whole thing in a "try & catch" to see if any error
>>> states are generated, but have never gotten any right side output at all.
>>>
>>> Does anyone have an idea that might make this work?
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/a76b897f-9f1f-4e82-ab18-344ae9a6e2c7%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Rob Reynolds
>> Developer, Puppet Labs
>>
>> *Join us at PuppetConf 2014 , September
>> 20-24 in San Francisco*
>>
>
>
>
> --
> Rob Reynolds
> Developer, Puppet Labs
>
> *Join us at PuppetConf 2014 , September
> 20-24 in San Francisco*
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/8m8mt4G_OKU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAMJiBK7GNgWponY1y74bpQ5x_YPbRcPeK3%3DmsyBc-W2txDfQaQ%40mail.gmail.com
> 
> .
>
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https:

Re: [Puppet Users] Using Powershell in facters yields no data

[Rob Reynolds]

On Thu, Sep 18, 2014 at 3:54 PM, Rob Reynolds  wrote:

>
>
> On Thu, Sep 18, 2014 at 2:11 PM, Brian Morris 
> wrote:
>
>> Hello all,
>>
>> I have been banging my head against this one for a couple of days. I am
>> trying to use Powershell to comb the Windows registry for installed
>> applications, such as VMware Tools, to create a custom facter. If I run
>> this code from a PS prompt it works, and returns the expected data:
>>
>> PS C:\> Get-ChildItem
>> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
>> {Get-ItemProperty $_.ps
>> path} | Where-Object {$_.DisplayName -eq "VMware Tools"} | ForEach-Object
>> -process {$_.DisplayVersion }
>> *9.4.6.1770165*
>>
>>
> This is running in a 64bit process.
>
>
>
>> However, running the same thing through Puppet as a facter yields zero
>> data:
>>
>> --
>> Facter.add("vmtools_version") do
>> confine :osfamily => "Windows"
>>   setcode do
>> 
>> Facter::Util::Resolution.exec('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
>> -Command
>>
>
C:\Windows\System32 is also subject to File system redirection, which is
also talked about in that post. Likely fixing only this as sysnative will
return the right data because PowerShell will run in 64bit mode. But I
would explore the ruby only way to speed up the fact.


> "& {Get-ChildItem
>> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
>> {Get-ItemProperty $_.pspath} | Where-Object {$_.DisplayName -eq \"VMware
>> Tools\"} | ForEach-Object -process {$_.DisplayVersion } } "')
>> end
>> end
>> --
>>
>
> This is in a 32bit process unless you are on the newest 3.7.0 or 3.7.1 x64
> builds of Puppet. You are hitting registry redirection.  Be sure to
> checkout Common Gotchas[1] especially for how to turn off registry
> redirection in a 32 bit process.
>
>
> [1] http://puppetlabs.com/blog/how-avoid-common-windows-gotchas-puppet
>
>
> More detail:
>
> When a 32 bit process calls the registry and is subject to redirection, it
> only sees the Wow6432Node under software. Check out that link above, it
> explains quite a bit in more detail.
>
>
>
>>
>> The left side shows up in the facters as "vmtools_version", but the right
>> side is always empty. I have tried using the  GetItem module instead, and
>> tried various combinations of the "-Command" switch, removed the "For-Each"
>> handler to see if would spit out a huge block of text, and even tried
>> wrapping the whole thing in a "try & catch" to see if any error states are
>> generated, but have never gotten any right side output at all.
>>
>> Does anyone have an idea that might make this work?
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/a76b897f-9f1f-4e82-ab18-344ae9a6e2c7%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Rob Reynolds
> Developer, Puppet Labs
>
> *Join us at PuppetConf 2014 , September
> 20-24 in San Francisco*
>



-- 
Rob Reynolds
Developer, Puppet Labs

*Join us at PuppetConf 2014 , September
20-24 in San Francisco*

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAMJiBK7GNgWponY1y74bpQ5x_YPbRcPeK3%3DmsyBc-W2txDfQaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Using Powershell in facters yields no data

[Rob Reynolds]

On Thu, Sep 18, 2014 at 2:11 PM, Brian Morris 
wrote:

> Hello all,
>
> I have been banging my head against this one for a couple of days. I am
> trying to use Powershell to comb the Windows registry for installed
> applications, such as VMware Tools, to create a custom facter. If I run
> this code from a PS prompt it works, and returns the expected data:
>
> PS C:\> Get-ChildItem
> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
> {Get-ItemProperty $_.ps
> path} | Where-Object {$_.DisplayName -eq "VMware Tools"} | ForEach-Object
> -process {$_.DisplayVersion }
> *9.4.6.1770165*
>
>
This is running in a 64bit process.



> However, running the same thing through Puppet as a facter yields zero
> data:
>
> --
> Facter.add("vmtools_version") do
> confine :osfamily => "Windows"
>   setcode do
> 
> Facter::Util::Resolution.exec('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
> -Command "& {Get-ChildItem
> hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object
> {Get-ItemProperty $_.pspath} | Where-Object {$_.DisplayName -eq \"VMware
> Tools\"} | ForEach-Object -process {$_.DisplayVersion } } "')
> end
> end
> --
>

This is in a 32bit process unless you are on the newest 3.7.0 or 3.7.1 x64
builds of Puppet. You are hitting registry redirection.  Be sure to
checkout Common Gotchas[1] especially for how to turn off registry
redirection in a 32 bit process.


[1] http://puppetlabs.com/blog/how-avoid-common-windows-gotchas-puppet


More detail:

When a 32 bit process calls the registry and is subject to redirection, it
only sees the Wow6432Node under software. Check out that link above, it
explains quite a bit in more detail.



>
> The left side shows up in the facters as "vmtools_version", but the right
> side is always empty. I have tried using the  GetItem module instead, and
> tried various combinations of the "-Command" switch, removed the "For-Each"
> handler to see if would spit out a huge block of text, and even tried
> wrapping the whole thing in a "try & catch" to see if any error states are
> generated, but have never gotten any right side output at all.
>
> Does anyone have an idea that might make this work?
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/a76b897f-9f1f-4e82-ab18-344ae9a6e2c7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Rob Reynolds
Developer, Puppet Labs

*Join us at PuppetConf 2014 , September
20-24 in San Francisco*

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAMJiBK5Ja%2B-4y-CEu%2BkO_rwQs2oQwM%2BTM%2BhU8wFA_AaT1BhP%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Best practices: client/server VS Git

[Trevor Vaughan]

It depends on how you organize/protect your repos.

If you use something like Gitolite, you can restrict branches to specific
users which would let you enforce central isolation.

However, a mistake on a branch or permissions could indeed lead to
sensitive information leaks.

Trevor

On Thu, Sep 18, 2014 at 4:26 PM, Julien Deloubes 
wrote:

> Old topic but i was wondering how secure is the git masterless setup.
> Do you have to separate each node configuration in a git branch or sub
> directory?
> I mean if you git clone the whole repo isn't a bit dangerous to have all
> the configuration on the node?
> In a master/agent configuration the configuration code is never locally on
> the node.
> Thanks.
>
> Le mercredi 26 février 2014 16:59:54 UTC+1, Julien Deloubes a écrit :
>>
>> Very interesting , thanks for your feedbacks.
>>
>> Le mardi 25 février 2014 15:09:43 UTC+1, Ken Barber a écrit :
>>>
>>> > This is the approach we are currently taking and it allows you to use
>>> > virtual resources. This is the only thing which should drive you to
>>> this
>>> > setup - the other is much simpler in my opinion. Of course there might
>>> > be a way to use a central PuppetDB service in masterless setup but at
>>> > least I am unaware of how to do this.
>>>
>>> It is possible:
>>>
>>> http://docs.puppetlabs.com/puppetdb/1.6/connect_puppet_apply.html
>>>
>>> ken.
>>>
>>  --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/d7eb43a3-0a17-4192-98e8-4de7ae73b140%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CANs%2BFoU3chQBQyC%3DVbKpK3tAxa1Uprbc6ToWnkcF0uvY2PkAyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Best practices: client/server VS Git

[Julien Deloubes]

Old topic but i was wondering how secure is the git masterless setup.
Do you have to separate each node configuration in a git branch or sub 
directory?
I mean if you git clone the whole repo isn't a bit dangerous to have all 
the configuration on the node?
In a master/agent configuration the configuration code is never locally on 
the node.
Thanks.

Le mercredi 26 février 2014 16:59:54 UTC+1, Julien Deloubes a écrit :
>
> Very interesting , thanks for your feedbacks.
>
> Le mardi 25 février 2014 15:09:43 UTC+1, Ken Barber a écrit :
>>
>> > This is the approach we are currently taking and it allows you to use 
>> > virtual resources. This is the only thing which should drive you to 
>> this 
>> > setup - the other is much simpler in my opinion. Of course there might 
>> > be a way to use a central PuppetDB service in masterless setup but at 
>> > least I am unaware of how to do this. 
>>
>> It is possible: 
>>
>> http://docs.puppetlabs.com/puppetdb/1.6/connect_puppet_apply.html 
>>
>> ken. 
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d7eb43a3-0a17-4192-98e8-4de7ae73b140%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Constant "end of file reached"

[Steve Perry]

Thanks for the reply Kylo - 

We were running puppet 3.7.1-1.  After seeing this, I checked the keep 
alive settings in httpd.conf and KeepAlive was off.  After enabling 
KeepAlive and setting it to 15 seconds, I was still seeing the same issue.

I took a snapshot of the virtual machine and then downgraded the puppet 
master/agent to 3.6.2-1 (changed KeepAlive back to off) and I'm still 
seeing the error:

Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: end of file reached
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading external facts from /etc/puppet/modules/puppet/facts.d
Info: Loading facts in 
/etc/puppet/modules/concat/lib/facter/concat_basedir.rb
Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/facter_dot_d.rb
Info: Loading facts in 
/etc/puppet/modules/stdlib/lib/facter/puppet_vardir.rb
Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/root_home.rb
Info: Loading facts in /etc/puppet/modules/stdlib/lib/facter/pe_version.rb
Info: Loading facts in 
/etc/puppet/modules/apt/lib/facter/apt_package_updates.rb
Info: Loading facts in /etc/puppet/modules/apt/lib/facter/apt_updates.rb
Info: Loading facts in 
/etc/puppet/modules/apt/lib/facter/apt_security_updates.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/apt_package_updates.rb
Info: Loading facts in /var/lib/puppet/lib/facter/apt_updates.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/apt_security_updates.rb
*Error: Could not retrieve catalog from remote server: end of file reached*
*Warning: Not using cache on failed catalog*
*Error: Could not retrieve catalog; skipping run*

On Thursday, September 18, 2014 12:47:44 PM UTC-4, Kylo Ginsberg wrote:
>
> On Thu, Sep 18, 2014 at 9:37 AM, Steve Perry  > wrote:
>
>> Wondering if anyone has seen this issue before:
>>
>> [root@xxpuppet2 puppet]# puppet agent -t
>> Warning: Unable to fetch my node definition, but the agent run will 
>> continue:
>> Warning: end of file reached
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Error: /File[/var/lib/puppet/lib]: Failed to generate additional 
>> resources using 'eval_generate': end of file reached
>> Info: Loading facts
>> Error: Could not retrieve catalog from remote server: end of file reached
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>> [root@xxpuppet2 puppet]#
>>
>> I am seeing this happen on every node that runs against this master. 
>>  This seems to have started randomly...
>>
>
> Hi Steve,
>
> What version of puppet are you running?
>
> If you recently upgraded to 3.7.x, you could be seeing 
> https://tickets.puppetlabs.com/browse/PUP-3238. The tldr there is that 
> the new http_keepalive_timeout setting should be less than the puppet 
> master's keep alive timeout (e.g. KeepAliveTimeout on apache).
>
> Thanks!
> Kylo
>  

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/26589fd6-6129-4b81-80b8-dd8ca2b6fb44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Using Powershell in facters yields no data

[Brian Morris]

I almost forgot. I have also tried setting the exec line up as a variable, 
and returning that variable, to no effect.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/0f3bf46f-7b96-4035-80a7-2293a0e2e30a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet 3.6.2: future parser + extlookup() + environment based selector

[Sergey Arlashin]

Hi!

We use puppet 3.6.2 with several environments. One of them is vagrant based 
environment called 'localdev' which is intended for local use only. Also we 
keep all the secret data like passwords and related stuff in csv files which 
reside in separate repository. We use extlookup() function to get the data from 
these csv files. And of course this repo with secret data is unavailable for 
those ones who work with vagrant based environment 'localdev'. 

For example some of our code looks like this:

smtp_password => $::environment ? {
  default => extlookup('smtp_password'),
  'localdev' => 'password'
},

When puppet is working with 'localdev' environment it does NOT try to execute 
extlookup() function at all. That's what we need.

With current parser everything worked without any problems. But today I tried 
to run our manifests with future parser enabled in 'localdev' environment. And 
got the following error:

==> node1: Error: No match found for 'smtp_password' in any data file during 
extlookup() on node node1.site
==> node1: Error: No match found for 'smtp_password' in any data file during 
extlookup() on node node1.site

I assume that future parser tries to execute extlookup() function even if the 
current environment is 'localdev'. 

So I'm wondering if it is a bug? Or may be it is a normal behaviour of future 
parser ?
 
I hope I explained everything correctly :)

Thanks in advance!

--
Best regards,
Sergey Arlashin

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7D151217-05A3-45B7-940B-5638EFFA1622%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Using Powershell in facters yields no data

[Brian Morris]

Hello all,

I have been banging my head against this one for a couple of days. I am 
trying to use Powershell to comb the Windows registry for installed 
applications, such as VMware Tools, to create a custom facter. If I run 
this code from a PS prompt it works, and returns the expected data:

PS C:\> Get-ChildItem 
hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object 
{Get-ItemProperty $_.ps
path} | Where-Object {$_.DisplayName -eq "VMware Tools"} | ForEach-Object 
-process {$_.DisplayVersion }
*9.4.6.1770165*

However, running the same thing through Puppet as a facter yields zero data:

--
Facter.add("vmtools_version") do
confine :osfamily => "Windows"
  setcode do

Facter::Util::Resolution.exec('C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
 
-Command "& {Get-ChildItem 
hklm:\software\microsoft\windows\currentversion\uninstall | ForEach-Object 
{Get-ItemProperty $_.pspath} | Where-Object {$_.DisplayName -eq \"VMware 
Tools\"} | ForEach-Object -process {$_.DisplayVersion } } "')
end
end
--

The left side shows up in the facters as "vmtools_version", but the right 
side is always empty. I have tried using the  GetItem module instead, and 
tried various combinations of the "-Command" switch, removed the "For-Each" 
handler to see if would spit out a huge block of text, and even tried 
wrapping the whole thing in a "try & catch" to see if any error states are 
generated, but have never gotten any right side output at all.

Does anyone have an idea that might make this work?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a76b897f-9f1f-4e82-ab18-344ae9a6e2c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Constant "end of file reached"

[Kylo Ginsberg]

On Thu, Sep 18, 2014 at 9:37 AM, Steve Perry  wrote:

> Wondering if anyone has seen this issue before:
>
> [root@xxpuppet2 puppet]# puppet agent -t
> Warning: Unable to fetch my node definition, but the agent run will
> continue:
> Warning: end of file reached
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources
> using 'eval_generate': end of file reached
> Info: Loading facts
> Error: Could not retrieve catalog from remote server: end of file reached
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> [root@xxpuppet2 puppet]#
>
> I am seeing this happen on every node that runs against this master.  This
> seems to have started randomly...
>

Hi Steve,

What version of puppet are you running?

If you recently upgraded to 3.7.x, you could be seeing
https://tickets.puppetlabs.com/browse/PUP-3238. The tldr there is that the
new http_keepalive_timeout setting should be less than the puppet master's
keep alive timeout (e.g. KeepAliveTimeout on apache).

Thanks!
Kylo

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CALsUZFFFwq2VDtS-_%3DbJX8HSqP%2BCYW4gHNQ6s0t3QTg%2Bt4gEtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Constant "end of file reached"

[Steve Perry]

Wondering if anyone has seen this issue before:

[root@xxpuppet2 puppet]# puppet agent -t
Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: end of file reached
Info: Retrieving pluginfacts
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
using 'eval_generate': end of file reached
Info: Loading facts
Error: Could not retrieve catalog from remote server: end of file reached
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
[root@xxpuppet2 puppet]#

I am seeing this happen on every node that runs against this master.  This 
seems to have started randomly...

Any insight would be greatly appreciated.




-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7c3b8e1d-d903-4210-aabf-5f0228f5ef53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble with Facter

[Jonathan Gazeley]

On 18/09/14 15:53, jcbollinger wrote:



On Thursday, September 18, 2014 9:26:12 AM UTC-5, Jonathan Gazeley wrote:

On 18/09/14 14:27, jcbollinger wrote:




2) The get_data() function relies on the ::serialnumber fact.  I
am uncertain how that fact is computed, but maybe something
changed that affected its result.


On Dell machines, the ::serialnumber fact returns the service tag
of the hardware. I have no idea how it retrieves that data, but it
only prints out the fact when run as root. Perhaps this is
breaking it, if this fact can't read other facts.



If Puppet is running as an unprivileged account on the client then 
that very likely would explain the problem, but that would be 
unusual.  There could also have been some kind of access control 
change around the mechanism by which the ::serialnumber is determined, 
but you already said you weren't seeing anything relevant in your 
audit log.


Our Puppet agent is running as root, so this isn't the problem. And yes, 
the audit log doesn't turn up anything relevant.



3) The get_data() function uses a local cache to avoid calling
the Dell API every time.  If that cache has been corrupted but
not altogether removed then perhaps get_data() would fail.


It's a possibility that I will investigate. In the meantime,
thanks for your suggestions.



Any way around, you could consider modifying the implementations of 
the ::warranty_start, ::warranty_end, and ::warranty_days_left facts 
to handle this situation more gracefully.  I account them flawed for 
not doing so now.




I think you are correct and this needs some dev work. However, this 
isn't my code (I inherited it) and I don't have the time to work on 
these facts which are not really used in my environment. Therefore, 
sadly I'm going to remove these facts to silence the warnings and get on 
with my other work.


Thanks John and Trevor for your help - at least I learned something 
along the way, and that's never a waste of time.


Cheers,
Jonathan

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/541AF2D0.9070605%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble with Facter

[jcbollinger]

On Thursday, September 18, 2014 9:26:12 AM UTC-5, Jonathan Gazeley wrote:
>
>  On 18/09/14 14:27, jcbollinger wrote:
>

 

>
>  2) The get_data() function relies on the ::serialnumber fact.  I am 
> uncertain how that fact is computed, but maybe something changed that 
> affected its result.
>  
>
> On Dell machines, the ::serialnumber fact returns the service tag of the 
> hardware. I have no idea how it retrieves that data, but it only prints out 
> the fact when run as root. Perhaps this is breaking it, if this fact can't 
> read other facts.
>
>

If Puppet is running as an unprivileged account on the client then that 
very likely would explain the problem, but that would be unusual.  There 
could also have been some kind of access control change around the 
mechanism by which the ::serialnumber is determined, but you already said 
you weren't seeing anything relevant in your audit log.

 

>  3) The get_data() function uses a local cache to avoid calling the Dell 
> API every time.  If that cache has been corrupted but not altogether 
> removed then perhaps get_data() would fail.
>  
>
> It's a possibility that I will investigate. In the meantime, thanks for 
> your suggestions.
>
>

Any way around, you could consider modifying the implementations of the 
::warranty_start, ::warranty_end, and ::warranty_days_left facts to handle 
this situation more gracefully.  I account them flawed for not doing so now.


John

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9987c0cf-0466-4c2d-ba9b-97005873bf5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] About the "params" pattern

[jcbollinger]

On Wednesday, September 17, 2014 10:55:12 PM UTC-5, François Lafont wrote:
>
> Thank you for your answer. 
>
> Le 17/09/2014 17:12, jcbollinger a écrit : 
>
> >> class my_module ( 
> >>   $var1 = $my_module::params::var1, 
> >>   $var2 = $my_module::params::var2, 
> >> ) inherits my_module::params { 
> >> 
> >>   include my_module 
> >> 
> > 
> > 
> > There's no point to including class my_module inside its own definition. 
>   
> > Did you mean to include my_module::internal? 
>
> Yes exactly. Sorry for the mistake. 
>
> >> class my_module::internal { 
> >> 
> >>   file { '/tmp/test_internal.txt': 
> >> content => template('test/test_internal.txt.erb'), 
> >>   } 
> >> 
> >>   notify { 'm1': message => "var1 = ${my_module::var1}", } 
> >>   notify { 'm2': message => "var2 = ${my_module::var2}", } 
> >>   notify { 'm3': message => "foo1 = ${my_module::foo1}", } 
> >>   notify { 'm4': message => "foo2 = ${my_module::foo2}", } 
> >> 
> >> } 
> >> 
> >> It's curious because I use no inheritance in my_module::internal, 
> >> no require etc. and despite that I can access to the variables of 
> >> my_module. Is it normal? 
> >> 
> >> 
> > 
> > It is very poor form to access $my_module::params::foo1 and 
> > $my_module::params::foo2 via inheriting class my_module (i.e. as 
> > ${my_module::foo1}, etc.). 
>
> But the my_module::internal inherits no class, so doesn't inherit 
> my_module class? I don't see where is the inheritance in the code 
> above. 
>
>

Sorry, I worded that very poorly.

Class my_module inherits my_module::params.  Absent my_module declaring its 
own local variables $foo1 and $foo2, the inheritance results in variables 
$::my_module::params::foo1 and $::my_module::params::foo2 being accessible 
unqualified in class my_module's namespace.  Because those variables are 
accessible unqualified in class my_module, they are also accessible 
elsewhere qualified by namespace my_module (i.e. $::my_module::foo1) -- 
*that* little bit of evil should not be used.  Instead, always qualify 
variable references with the namespace in which the variable is actually 
declared (my_module::params in this case).

 

> Or, if I understand well, when I have: 
>
> class my_module { 
> include my_module::internal 
> } 
>
> I can say: "my_module::internal" inherits my_module. Is that correct? 
>
>

No, not at all.  My apologies for the confusion.

 

>
> > With that out of the way, it is better to say 
> > that the result you observe is among the valid possibilities than to say 
> it 
> > is "normal". 
> > 
> > All class variables have global visibility regardless of inheritance or 
> > declaration (e.g. via include / require).   
>
> Do you mean that with: 
>
> class my_module { 
> include my_module::internal 
> } 
>
> In the body of my_module::internal class I can access to the variables 
> defined in my_module class? With a unqualified name? 
>


No, not in the slightest.  I mean that if class my_module::params has a 
local variable with unqualified name "foo1", then that variable can be 
referenced from any class in any module as $my_module::params::foo1, 
regardless of any inheritance or include / require / contain statements 
anywhere.  Under some inheritance-related circumstances it can also be 
referenced in certain places via its unqualified name, but as a matter of 
form, it should be accessed only via its qualified name anywhere outside 
class my_module::params.

The main role of inheritance and the only role of include / require / 
contain with respect to class variables is as I described before:


> > The main purpose of all that *as 
> > it pertains to variables* is to ensure that Puppet evaluates classes 
> during 
> > catalog compilation in an order that assigns values to those variables 
> > before those values are used.  It also serves a documentary purpose, 
> > showing clearly that one class has a dependency on another. 
> > 
> >   
> > 
> >> One thing very curious too: in the my_module::internal class 
> >> I can access to $var1 with this syntax : 
> >> 
> >> ${my_module::var1} 
> >> 
> > 
> > 
> > No, you can't.  There is no $var1 in class my_module::internal, so you 
> are 
> > not accessing such a variable.  You are instead accessing 
> > $my_module::params::var1 via an alias (that alias resulting from class 
> > my_module inheriting my_module::params).  Don't use that alias, even in 
> > class my_module. 
>
> Ok. 
>


No, not ok, my apologies.  There is after all a $my_module:var1 -- it is a 
class parameter.  I overlooked that this is a different case from the 
$my_module::foo1 case discussed above.  So, it's right and fine to refer to 
$my_module::var1 if that's what you actually mean.

 

>
> >> and $var1 is empty. Ok, I think I understand that. But in my 
> >> template "test_internal.txt.erb" I can use directly: 
> >> 
> >> blabla <%= @var1 %> blabla 
> >> 
> >> without the fully qualified name. Here, I don't understand. 
> >> 
> > 
> > 
> > I don't believe you. 
>
> I

Re: [Puppet Users] Trouble with Facter

[Jonathan Gazeley]

On 18/09/14 14:27, jcbollinger wrote:



On Thursday, September 18, 2014 4:36:16 AM UTC-5, Jonathan Gazeley wrote:



Could not retrieve fact='warranty_start',
resolution='': undefined method `[]' for nil:NilClass
Could not retrieve fact='warranty_end', resolution='':
undefined method `[]' for nil:NilClass
Could not retrieve fact='warranty_end', resolution='':
undefined method `[]' for nil:NilClass
Could not retrieve fact='warranty_days_left',
resolution='': can't dup NilClass



That suggests to me that you have moved on to a different issue.  
Matching up the code (facter/warranty.rb and facter/util/warranty.rb) 
with the error messages you report, it seems likely that function 
Facter::Util::Warranty::get_data() is failing on you.  That will cause 
both Facter::Util::Warranty::purchase_date() and the 
Facter::Util::Warranty::warranties() to return nil.  The 
::warranty_start, ::warranty_end, and ::warranty_days_left facts all 
depend on those two functions, assuming without testing that they 
never return nil, hence the observed errors.


OK



As to why get_data() may be failing, it looks like there are several 
possibilities:


1) The function relies on calling an HTTP API at Dell to retrieve data 
(lines 6-12 and 60-72).  It may be that that API has been modified or 
removed, or that it no longer serves data for the particular machines 
in question.


A quick test using a web browser suggests that the API is still present, 
working, and returning valid data


2) The get_data() function relies on the ::serialnumber fact.  I am 
uncertain how that fact is computed, but maybe something changed that 
affected its result.


On Dell machines, the ::serialnumber fact returns the service tag of the 
hardware. I have no idea how it retrieves that data, but it only prints 
out the fact when run as root. Perhaps this is breaking it, if this fact 
can't read other facts.


3) The get_data() function uses a local cache to avoid calling the 
Dell API every time.  If that cache has been corrupted but not 
altogether removed then perhaps get_data() would fail.


It's a possibility that I will investigate. In the meantime, thanks for 
your suggestions.


Cheers,
Jonathan

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/541AEB73.4080201%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble with Facter

[jcbollinger]

On Thursday, September 18, 2014 4:36:16 AM UTC-5, Jonathan Gazeley wrote:
>
> On 17/09/14 17:29, Trevor Vaughan wrote: 
> > Ah, so looking at warranty.rb and then stdlib...puppet_vardir.rb, you 
> > may be missing this: 
> > 
> > begin 
> >   require 'facter/util/puppet_settings' 
> > rescue LoadError => e 
> >   # puppet apply does not add module lib directories to the $LOAD_PATH 
> > (See 
> >   # #4248). It should (in the future) but for the time being we need to 
> be 
> >   # defensive which is what this rescue block is doing. 
> >   rb_file = File.join(File.dirname(__FILE__), 'util', 
> > 'puppet_settings.rb') 
> >   load rb_file if File.exists?(rb_file) or raise e 
> > end 
> > 
>
> Thanks. I added a similar block of code to load util/warranty.rb but it 
> didn't cure the situation. Something is different though. Running facter 
> by hand no longer complains, but my 15-minutely emails from MCollective 
> as it tries to cache facts are still being sent: 
>
> Could not retrieve fact='warranty_start', resolution='': 
> undefined method `[]' for nil:NilClass 
> Could not retrieve fact='warranty_end', resolution='': 
> undefined method `[]' for nil:NilClass 
> Could not retrieve fact='warranty_end', resolution='': 
> undefined method `[]' for nil:NilClass 
> Could not retrieve fact='warranty_days_left', resolution='': 
> can't dup NilClass 
>
>

That suggests to me that you have moved on to a different issue.  Matching 
up the code (facter/warranty.rb and facter/util/warranty.rb) with the error 
messages you report, it seems likely that function 
Facter::Util::Warranty::get_data() is failing on you.  That will cause both 
Facter::Util::Warranty::purchase_date() and the 
Facter::Util::Warranty::warranties() to return nil.  The ::warranty_start, 
::warranty_end, and ::warranty_days_left facts all depend on those two 
functions, assuming without testing that they never return nil, hence the 
observed errors.

As to why get_data() may be failing, it looks like there are several 
possibilities:

1) The function relies on calling an HTTP API at Dell to retrieve data 
(lines 6-12 and 60-72).  It may be that that API has been modified or 
removed, or that it no longer serves data for the particular machines in 
question.
2) The get_data() function relies on the ::serialnumber fact.  I am 
uncertain how that fact is computed, but maybe something changed that 
affected its result.
3) The get_data() function uses a local cache to avoid calling the Dell API 
every time.  If that cache has been corrupted but not altogether removed 
then perhaps get_data() would fail.
 
In addition, the local caching also means that, depending on the cache 
timeout, the change that triggered the error might have happened some time 
before the error started appearing.



> BTW #4248 is a very old bug, surely it's still not being hit? 
>
> https://projects.puppetlabs.com/issues/4248 
>
>

That's not your issue.  It pertains to plugin classes on the master that 
are present only in their modules (i.e. they have not yet been 
plugin-synced to the master itself).  Facts are the one plugin type to 
which that bug cannot apply.


John

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c83389a6-bb71-42a3-a7cd-3ebf6abb4d40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble with Facter

[Jonathan Gazeley]

On 17/09/14 17:29, Trevor Vaughan wrote:
Ah, so looking at warranty.rb and then stdlib...puppet_vardir.rb, you 
may be missing this:


begin
  require 'facter/util/puppet_settings'
rescue LoadError => e
  # puppet apply does not add module lib directories to the $LOAD_PATH 
(See

  # #4248). It should (in the future) but for the time being we need to be
  # defensive which is what this rescue block is doing.
  rb_file = File.join(File.dirname(__FILE__), 'util', 
'puppet_settings.rb')

  load rb_file if File.exists?(rb_file) or raise e
end



Thanks. I added a similar block of code to load util/warranty.rb but it 
didn't cure the situation. Something is different though. Running facter 
by hand no longer complains, but my 15-minutely emails from MCollective 
as it tries to cache facts are still being sent:


Could not retrieve fact='warranty_start', resolution='': undefined 
method `[]' for nil:NilClass
Could not retrieve fact='warranty_end', resolution='': undefined 
method `[]' for nil:NilClass
Could not retrieve fact='warranty_end', resolution='': undefined 
method `[]' for nil:NilClass
Could not retrieve fact='warranty_days_left', resolution='': can't 
dup NilClass


BTW #4248 is a very old bug, surely it's still not being hit?

https://projects.puppetlabs.com/issues/4248

I'm out of the office for a couple hours but I'll some more time into 
this a bit later this afternoon.


Cheers,
Jonathan

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/541AA781.206%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.