Re: [Puppet Users] referencing boolean within puppet manifest

[Mike Reed]

Thank you for the explanation Garrett.  I've seen similar things like that 
in my web searches but failed to put it all together.

I'll roll with this until we upgrade to 4.0

Cheers,

Mike

On Tuesday, April 12, 2016 at 6:31:47 PM UTC-7, Garrett Honeycutt wrote:
>
> On 4/12/16 2:53 PM, Mike Reed wrote: 
> > Hello all, 
> > 
> > I've recently experienced some inconsistencies around referencing 
> > Boolean values within a puppet manifest.  We've written some custom 
> > Boolean facts and we look to the true/false values within our manifests 
> > to help make decisions on what should or shouldn't be done. 
> > 
> > The issue I have is the different behavior I see when referencing the 
> > fact value.  For instance, in some cases I have to reference the Boolean 
> > value with quotes (ie.. 'true') in order to get things working right. 
> >  In other cases, removing the quotes returns the results I would expect. 
> > 
> > I understand that this is most likely due to what the fact is returning 
> > but I was wondering if there's a 'best practice' for approaching 
> > something like this.  I've also played around with stringify_facts and 
> > achieved varied results (in terms of referencing the Boolean values) and 
> > that may have only confused me.   
> > 
> > We're currently running: Puppet v:3.8.6/Hiera v:1.3.4 
> > 
> > I realize this question touches on a few different things but does 
> > anybody have a brief explanation for how I might consistently reference 
> > these Boolean values throughout our puppet infrastructure?   
> > 
> > Here's an example of a custom fact that we use: 
> > 
> > require 'facter' 
> > 
> > Facter.add(:nvidia_installed) do 
> >   setcode do 
> > tools_test = Facter::Util::Resolution.exec("/usr/bin/nvidia-smi") 
> > if tools_test 
> >   nvidia_installed = true 
> > else 
> >   nvidia_installed = false 
> > end 
> >   end 
> > end 
> > 
> > In order to reference this particular value within my manifest, I have 
> > to reference the value without quotes:   elsif ($::class == 
> > 'render_workstation') and ($::nvidia_installed == false) { 
> > 
> > As always, thank you in advance for the help and support. 
> > 
> > Cheers, 
> > 
> > Mike 
> > 
>
> Hi Mike, 
>
> Booleans such as true vs. stringified booleans such as 'true' have long 
> been a sore spot within the Puppet ecosystem. 
>
> You want to set stringify_facts = false in your puppet.conf. This will 
> allow you to have other data types as facts such as booleans, arrays, 
> and hashes. 
>
> Recommend using this design pattern to deal with stringified booleans in 
> Puppet v3. 
>
>   if is_string($my_param) == true { 
> $my_param_bool = str2bool($my_param) 
>   } else { 
> $my_param_bool = $my_param 
>   } 
>   validate_bool($my_param_bool) 
>
> So given the param, $my_param, this will ensure it is an actual boolean. 
> In your code you reference $my_param_bool instead of $my_param. 
>
>
> Best regards, 
> -g 
>
> -- 
> Garrett Honeycutt 
> @learnpuppet 
> Puppet Training with LearnPuppet.com 
> Mobile: +1.206.414.8658 
>

-- 
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/a3a388d6-c037-4029-bdf3-d4abed521f1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] referencing boolean within puppet manifest

[Mike Reed]

Hello all,

I've recently experienced some inconsistencies around referencing Boolean 
values within a puppet manifest.  We've written some custom Boolean facts 
and we look to the true/false values within our manifests to help make 
decisions on what should or shouldn't be done.

The issue I have is the different behavior I see when referencing the fact 
value.  For instance, in some cases I have to reference the Boolean value 
with quotes (ie.. 'true') in order to get things working right.  In other 
cases, removing the quotes returns the results I would expect.

I understand that this is most likely due to what the fact is returning but 
I was wondering if there's a 'best practice' for approaching something like 
this.  I've also played around with stringify_facts and achieved varied 
results (in terms of referencing the Boolean values) and that may have only 
confused me.  

We're currently running: Puppet v:3.8.6/Hiera v:1.3.4

I realize this question touches on a few different things but does anybody 
have a brief explanation for how I might consistently reference these 
Boolean values throughout our puppet infrastructure?  

Here's an example of a custom fact that we use:

require 'facter'

Facter.add(:nvidia_installed) do
  setcode do
tools_test = Facter::Util::Resolution.exec("/usr/bin/nvidia-smi")
if tools_test
  nvidia_installed = true
else
  nvidia_installed = false
end
  end
end

In order to reference this particular value within my manifest, I have to 
reference the value without quotes:   elsif ($::class == 
'render_workstation') and ($::nvidia_installed == false) {

As always, thank you in advance for the help and support.

Cheers,

Mike


-- 
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/24c74385-59e2-4610-8915-0ead4ac52e72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter value - not returning expected result

[Mike Reed]

Hey Peter,

In the original code you provided me, the '$?' was the thing that was 
confusing me.  After some reading (and realizing my stupidity), I 
understand now that whatever is returned from #exec is what's passed to the 
block as the return value.  If I run my #exec on from a bash shell, after a 
successful run, I am returned the domain name (as that's what I'm grepping 
out).  Obviously, the returned domain name is not a boolean and thus, I'm 
comparing a string to a boolean value.

As you stated, it looks like my only option of getting the exit code is via 
'$?' so that's what I'll roll with.

Again, thank you very much.  I owe you a beer.

Cheers mate,

Mike.

On Thursday, March 24, 2016 at 4:08:09 PM UTC-7, Peter Huene wrote:
>
> Hi Mike,
>
> On Thu, Mar 24, 2016 at 3:58 PM, Mike Reed  > wrote:
>
>> Hey Peter,
>>
>> I've done some additional reading and I believe I understand what's 
>> happening now.   
>>
>> Thank you very much for the information and help.
>>
>
> Glad you got things working; let me know if there are any other questions 
> that come up.  
>  
>
>>
>> Cheers,
>>
>> Mike
>>
>>
>> On Thursday, March 24, 2016 at 2:25:38 PM UTC-7, Mike Reed wrote:
>>>
>>> Hey Peter,
>>>
>>> Thank you for the reply and the information.
>>>
>>> In terms of the piped greps, the second  string is actually our 
>>> internal domain name (which I removed and replaced with ) for 
>>> security sake.
>>>
>>> I'm a little confused by code above as I'm still not getting what I 
>>> would expect from your code above.  I think part of my confusion is how the 
>>> recommended code gives me a true/false value.  I've changed the fact to now 
>>> look like this:
>>>
>>> require 'facter'
>>>
>>> Facter.add(:pbis_joined) do
>>>   setcode do
>>>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli 
>>> query | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>>>   end
>>> end
>>>
>>> The issue I'm seeing is that on a machine that is added to the domain, I 
>>> would expect the /opt/pbis...command to return true (as evidenced by the 
>>> exit status of zero on the command line).  However, upon running this new 
>>> fact, I get a value of: pbis_joined => false; even though I know the 
>>> machine is on the domain and running the command manually does give me an 
>>> exit status of '0' on this particular machine.  
>>>
>>> I tried this new fact on another machine that I know is not joined to 
>>> the domain and I do get a 'false' on that box.  
>>>
>>> If the problem is that #exec returns nil or a string; and being that I'm 
>>> looking to evaluate against an integer, could I not just do something like 
>>> 'domain_return.to_i' in the original code? 
>>>
>>
> I wasn't very clear on what #exec returns: the string it returns is the 
> stdout output of the executed process as a string; thus it would not 
> contain a representation of the exit code as you've already surmised.
>
> Unfortunately, right now Ruby's built-in `$?` global variable is the only 
> way of getting at the exit code from the executed process with the way the 
> Facter execution API is currently defined.
>  
>
>>
>>> I wanted to thank you again for your help.  It is very much appreciated.
>>>
>>> Cheers,
>>>
>>> Mike
>>>
>>>
>>>
>>> On Thursday, March 24, 2016 at 1:06:48 PM UTC-7, Peter Huene wrote:
>>>>
>>>> Hi Mike,
>>>>
>>>> On Thu, Mar 24, 2016 at 12:30 PM, Mike Reed  wrote:
>>>>
>>>>> Hey Peter,
>>>>>
>>>>> Thank you for the reply.
>>>>>
>>>>> If I run the command on a machine that I know is 'joined' to the 
>>>>> domain and run 'echo $?' immediately after, I get a return of '0'.  
>>>>>
>>>>
>>>> If you're going solely off of grep's exit status, try this:
>>>>
>>>> ```
>>>> Facter.add(:pbis_joined) do
>>>>   setcode do
>>>>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli 
>>>> query | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>>>>   end

Re: [Puppet Users] facter value - not returning expected result

[Mike Reed]

Hey Peter,

I've done some additional reading and I believe I understand what's 
happening now.   

Thank you very much for the information and help.

Cheers,

Mike

On Thursday, March 24, 2016 at 2:25:38 PM UTC-7, Mike Reed wrote:
>
> Hey Peter,
>
> Thank you for the reply and the information.
>
> In terms of the piped greps, the second  string is actually our 
> internal domain name (which I removed and replaced with ) for 
> security sake.
>
> I'm a little confused by code above as I'm still not getting what I would 
> expect from your code above.  I think part of my confusion is how the 
> recommended code gives me a true/false value.  I've changed the fact to now 
> look like this:
>
> require 'facter'
>
> Facter.add(:pbis_joined) do
>   setcode do
>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query 
> | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>   end
> end
>
> The issue I'm seeing is that on a machine that is added to the domain, I 
> would expect the /opt/pbis...command to return true (as evidenced by the 
> exit status of zero on the command line).  However, upon running this new 
> fact, I get a value of: pbis_joined => false; even though I know the 
> machine is on the domain and running the command manually does give me an 
> exit status of '0' on this particular machine.  
>
> I tried this new fact on another machine that I know is not joined to the 
> domain and I do get a 'false' on that box.  
>
> If the problem is that #exec returns nil or a string; and being that I'm 
> looking to evaluate against an integer, could I not just do something like 
> 'domain_return.to_i' in the original code? 
>
> I wanted to thank you again for your help.  It is very much appreciated.
>
> Cheers,
>
> Mike
>
>
>
> On Thursday, March 24, 2016 at 1:06:48 PM UTC-7, Peter Huene wrote:
>>
>> Hi Mike,
>>
>> On Thu, Mar 24, 2016 at 12:30 PM, Mike Reed  wrote:
>>
>>> Hey Peter,
>>>
>>> Thank you for the reply.
>>>
>>> If I run the command on a machine that I know is 'joined' to the domain 
>>> and run 'echo $?' immediately after, I get a return of '0'.  
>>>
>>
>> If you're going solely off of grep's exit status, try this:
>>
>> ```
>> Facter.add(:pbis_joined) do
>>   setcode do
>>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli 
>> query | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>>   end
>> end
>> ```
>>
>> Breaking that down:
>>
>> ```
>> !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query | 
>> grep -i 'domain' | grep -i ''}).nil?
>> ```
>>
>> This runs the command and ensures #exec doesn't return nil (which will 
>> happen if it failed to execute the command, e.g. command not found).
>>
>> ```
>> $?.success?
>> ```
>>
>> This ensures the executed process exited with a zero exit code (i.e. $? 
>> in a shell == 0).
>>
>> On an aside: do you need the piped greps?  Seems like the latter grep 
>> would be all that's needed assuming you're looking for just "", 
>> unless you intended this to be either "domain" or "", which won't 
>> work as currently constructed.
>>  
>>
>>>
>>> Thank you again,
>>>
>>> Mike
>>>
>>> On Thursday, March 24, 2016 at 12:13:53 PM UTC-7, Peter Huene wrote:
>>>>
>>>> Hi Mike,
>>>>
>>>> On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed  wrote:
>>>>
>>>>> Hey all,
>>>>>
>>>>> I'm a little stumped on why this fact is returning the incorrect value 
>>>>> and I was hoping somebody would have some advice on this one.
>>>>>
>>>>> The fact is very basic and looks like this:
>>>>>
>>>>> # custom fact for detecting if machine is joined to the domain
>>>>> require 'facter'
>>>>>
>>>>> Facter.add(:pbis_joined) do
>>>>>   setcode do
>>>>>   domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i 
>>>>> 'domain' | grep -i ''}
>>>>> domain_return = Facter::Util::Resolution.exec(domain_check)
>>>>> if domain_return == 0
>>>>>
>>>

Re: [Puppet Users] facter value - not returning expected result

[Mike Reed]

Hey Peter,

Thank you for the reply and the information.

In terms of the piped greps, the second  string is actually our 
internal domain name (which I removed and replaced with ) for 
security sake.

I'm a little confused by code above as I'm still not getting what I would 
expect from your code above.  I think part of my confusion is how the 
recommended code gives me a true/false value.  I've changed the fact to now 
look like this:

require 'facter'

Facter.add(:pbis_joined) do
  setcode do
  !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query 
| grep -i 'domain' | grep -i ''}).nil? && $?.success?
  end
end

The issue I'm seeing is that on a machine that is added to the domain, I 
would expect the /opt/pbis...command to return true (as evidenced by the 
exit status of zero on the command line).  However, upon running this new 
fact, I get a value of: pbis_joined => false; even though I know the 
machine is on the domain and running the command manually does give me an 
exit status of '0' on this particular machine.  

I tried this new fact on another machine that I know is not joined to the 
domain and I do get a 'false' on that box.  

If the problem is that #exec returns nil or a string; and being that I'm 
looking to evaluate against an integer, could I not just do something like 
'domain_return.to_i' in the original code? 

I wanted to thank you again for your help.  It is very much appreciated.

Cheers,

Mike



On Thursday, March 24, 2016 at 1:06:48 PM UTC-7, Peter Huene wrote:
>
> Hi Mike,
>
> On Thu, Mar 24, 2016 at 12:30 PM, Mike Reed  > wrote:
>
>> Hey Peter,
>>
>> Thank you for the reply.
>>
>> If I run the command on a machine that I know is 'joined' to the domain 
>> and run 'echo $?' immediately after, I get a return of '0'.  
>>
>
> If you're going solely off of grep's exit status, try this:
>
> ```
> Facter.add(:pbis_joined) do
>   setcode do
>   !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli 
> query | grep -i 'domain' | grep -i ''}).nil? && $?.success?
>   end
> end
> ```
>
> Breaking that down:
>
> ```
> !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query | 
> grep -i 'domain' | grep -i ''}).nil?
> ```
>
> This runs the command and ensures #exec doesn't return nil (which will 
> happen if it failed to execute the command, e.g. command not found).
>
> ```
> $?.success?
> ```
>
> This ensures the executed process exited with a zero exit code (i.e. $? in 
> a shell == 0).
>
> On an aside: do you need the piped greps?  Seems like the latter grep 
> would be all that's needed assuming you're looking for just "", 
> unless you intended this to be either "domain" or "", which won't 
> work as currently constructed.
>  
>
>>
>> Thank you again,
>>
>> Mike
>>
>> On Thursday, March 24, 2016 at 12:13:53 PM UTC-7, Peter Huene wrote:
>>>
>>> Hi Mike,
>>>
>>> On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed  wrote:
>>>
>>>> Hey all,
>>>>
>>>> I'm a little stumped on why this fact is returning the incorrect value 
>>>> and I was hoping somebody would have some advice on this one.
>>>>
>>>> The fact is very basic and looks like this:
>>>>
>>>> # custom fact for detecting if machine is joined to the domain
>>>> require 'facter'
>>>>
>>>> Facter.add(:pbis_joined) do
>>>>   setcode do
>>>>   domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i 
>>>> 'domain' | grep -i ''}
>>>> domain_return = Facter::Util::Resolution.exec(domain_check)
>>>> if domain_return == 0
>>>>
>>>
>>> Facter::Util::Resolution.exec returns the command's output as a string 
>>> or nil if the command failed.  Thus, I would expect this conditional 
>>> (`domain_return == 0`) to never evaluate to true because a string or a nil 
>>> can never equal 0.
>>>
>>> What does the command output if you run it manually when you expect the 
>>> `pbis_joined` facter to be true?
>>>  
>>>
>>>>   pbis_joined = true
>>>> else
>>>>   pbis_joined = false
>>>> end
>>>>   end
>>>> end
>>>>
>>>
>>> Also, the `pbis_joined` local variable serves no purpose here, as

Re: [Puppet Users] facter value - not returning expected result

[Mike Reed]

Hey Peter,

Thank you for the reply.

If I run the command on a machine that I know is 'joined' to the domain and 
run 'echo $?' immediately after, I get a return of '0'.  

Thank you again,

Mike

On Thursday, March 24, 2016 at 12:13:53 PM UTC-7, Peter Huene wrote:
>
> Hi Mike,
>
> On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed  > wrote:
>
>> Hey all,
>>
>> I'm a little stumped on why this fact is returning the incorrect value 
>> and I was hoping somebody would have some advice on this one.
>>
>> The fact is very basic and looks like this:
>>
>> # custom fact for detecting if machine is joined to the domain
>> require 'facter'
>>
>> Facter.add(:pbis_joined) do
>>   setcode do
>>   domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i 
>> 'domain' | grep -i ''}
>> domain_return = Facter::Util::Resolution.exec(domain_check)
>> if domain_return == 0
>>
>
> Facter::Util::Resolution.exec returns the command's output as a string or 
> nil if the command failed.  Thus, I would expect this conditional 
> (`domain_return == 0`) to never evaluate to true because a string or a nil 
> can never equal 0.
>
> What does the command output if you run it manually when you expect the 
> `pbis_joined` facter to be true?
>  
>
>>   pbis_joined = true
>> else
>>   pbis_joined = false
>> end
>>   end
>> end
>>
>
> Also, the `pbis_joined` local variable serves no purpose here, as it is 
> the return value from the block that sets the fact's value.
>  
>
>>
>> Regardless of whether the domain_check command is a success on the 
>> client, I always get a value of 'true' from the fact.  In fact, if I 
>> completely remove the /opt/pbis folder from the machine and run the fact 
>> again, I still get a value of 'true'.  Additionally, If I manually run the 
>> domain_check command on a machine that I know is not joined to the domain, 
>> I will still get a value of 'true' from the fact.  
>>
>> I've also tried both single '=' and double '==' for the 'if 
>> domain_return' piece of the fact and neither seem to give me what I want.  
>> I then thought that the domain_check object may not be considered an 
>> integer when comparing against the '0' so I added 'domain_return.to_i' and 
>> still got the same result.
>>
>> The code within the manifest that looks to this fact looks like this:  if 
>> ($::pbis_joined == true) {etc,etc,etc}
>>
>> I do have stringify_facts set to 'false' within puppet.conf on both the 
>> client and the master.
>>
>> Puppet version 3.6.2/Hiera version: 1.3.4
>>
>> Does anybody have any suggestions they can give me as to why I'm not 
>> getting the correct return value?
>>
>> As always, thanks to everybody for their help and support.
>>
>> Cheers,
>>
>> Mike
>>
>>
>>
>>
>>  
>>
>> -- 
>> 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/a1f8ece8-627b-478d-a108-97c91d76d654%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/a1f8ece8-627b-478d-a108-97c91d76d654%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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c7d8d40d-5121-426e-a208-a8a4af3bffb1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] facter value - not returning expected result

[Mike Reed]

Hey all,

I'm a little stumped on why this fact is returning the incorrect value and 
I was hoping somebody would have some advice on this one.

The fact is very basic and looks like this:

# custom fact for detecting if machine is joined to the domain
require 'facter'

Facter.add(:pbis_joined) do
  setcode do
  domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i 
'domain' | grep -i ''}
domain_return = Facter::Util::Resolution.exec(domain_check)
if domain_return == 0
  pbis_joined = true
else
  pbis_joined = false
end
  end
end

Regardless of whether the domain_check command is a success on the client, 
I always get a value of 'true' from the fact.  In fact, if I completely 
remove the /opt/pbis folder from the machine and run the fact again, I 
still get a value of 'true'.  Additionally, If I manually run the 
domain_check command on a machine that I know is not joined to the domain, 
I will still get a value of 'true' from the fact.  

I've also tried both single '=' and double '==' for the 'if domain_return' 
piece of the fact and neither seem to give me what I want.  I then thought 
that the domain_check object may not be considered an integer when 
comparing against the '0' so I added 'domain_return.to_i' and still got the 
same result.

The code within the manifest that looks to this fact looks like this:  if 
($::pbis_joined == true) {etc,etc,etc}

I do have stringify_facts set to 'false' within puppet.conf on both the 
client and the master.

Puppet version 3.6.2/Hiera version: 1.3.4

Does anybody have any suggestions they can give me as to why I'm not 
getting the correct return value?

As always, thanks to everybody for their help and support.

Cheers,

Mike




 

-- 
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/a1f8ece8-627b-478d-a108-97c91d76d654%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Iteration over fact array - index doesn't seem to work

[Mike Reed]

Hey John,

After changing 'stringify_facts' to false on both master and client, things 
are working as expected.

Thank you again for the insight; not sure how I missed that one.

Cheers,

Mike

On Wednesday, February 10, 2016 at 6:12:40 AM UTC-8, jcbollinger wrote:
>
>
>
> On Tuesday, February 9, 2016 at 5:00:12 PM UTC-6, Mike Reed wrote:
>  
>
>>
>> Running 'facter -p' on the client side (assuming we have two video cards 
>> installed), I receive a result of:  video_card_id => ["17c2", "17c2"]
>> This result means to me that I was returned two strings, each of which 
>> are contained within a typical ruby'ish collection.
>>
>> Now, if I try and reference the first item in the collection - like below 
>> - using video_card_id[0] within a puppet manifest, I get an error
>>
>> notify { "Installing driver version: ({$::video_card_id[0]})" : }
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on 
>> SERVER: ::video_card_id is not a hash or array when accessing it with 0.
>> [...]
>>
>
>  
>
>> Both server and client are running:  Puppet 3.6.2/Facter 2.1.0
>>
>>
> Structured facts were a forward-looking feature in Puppet 3.6, not enabled 
> by default.  When they are not enabled, Puppet squashes all fact values to 
> strings.  You must configure both the agent and the master to support 
> structured facts, by setting the stringify_facts configuration option to 
> false.  The docs discuss this 
> <https://docs.puppetlabs.com/puppet/3.6/reference/config_important_settings.html#recommended-and-safe>,
>  
> but they don't say much more than the above.
>
>
> 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/7104fab0-9373-4afe-aea2-3ff32289089e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Iteration over fact array - index doesn't seem to work

[Mike Reed]

Hello all,

I'm working with a custom fact that's returning an array as it's value. 
 The fact looks like this:

require 'facter'

Facter.add(:video_card_id) do
  confine :kernel => :linux
  setcode do 

# create array for card id's
id_array = Array.new
  
# determine id of card #
id_query  = %q{lspci | grep -i 'vga' | awk '{print $8}'}
id_return = Facter::Util::Resolution.exec(id_query)

# add id's to array
id_return.each { |id| id_array.push(id) }
id_array.map! { |x| x.chomp }

# return id array
id_array
  end
end


Running 'facter -p' on the client side (assuming we have two video cards 
installed), I receive a result of:  video_card_id => ["17c2", "17c2"]
This result means to me that I was returned two strings, each of which are 
contained within a typical ruby'ish collection.

Now, if I try and reference the first item in the collection - like below - 
using video_card_id[0] within a puppet manifest, I get an error

notify { "Installing driver version: ({$::video_card_id[0]})" : }

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
::video_card_id is not a hash or array when accessing it with 0.


This fact is part of a larger design that incorporates the fact's value 
into something like this:

class nvidia::config (
  $model_hash = {
  '009d' => "$::nvidia::params::quadro_fx_4500_driver",
  '06dc' => "$::nvidia::params::quadro_6000_driver",
  '06d9' => "$::nvidia::params::quadro_5000_driver",
  '11ba' => "$::nvidia::params::quadro_K5000_driver",
  '17c2' => "$::nvidia::params::gtx_titanx_driver",
  '17f0' => "$::nvidia::params::quadro_M6000_driver",
  }

) inherits nvidia::params {

  if ($::is_virtual == true) and ($::class == 'server') {
notify { 'This is a virtual machine and the nvidia driver doesn\'t get 
intalled' : 
  }

# only run nvidia installer if the machine is a workstation and the 
driver is not already installed
  } elsif ($::class == 'workstation') and ($::nvidia_installed == false ) { 
   
# let 'em know what you're doing
notify { "Installing driver version: 
${model_hash[$::video_card_id[0]]}" : }

# stop kde before driver install
exec { 'kdm-stop' :
  command => '/usr/bin/service kdm stop',
  unless  => '/usr/bin/service kdm status | grep -i "stop" ',
  before  => Exec['nvidia-driver-install'],
}

# install nvidia driver
exec { 'nvidia-driver-install' :
  command => "/usr/src/{$model_hash[$::video_card_id[0]]}.run -s -X 
-N --force-tls=new --no-x-check --no-cc-version-check",
  require => 
File["/usr/src/${model_hash[$::video_card_id[0]]}.run"],
  notify  => Exec['reboot_after_nvidia'],
}

# reboot after nvidia install
exec { 'reboot_after_nvidia' :
  command => "/sbin/reboot",
  refreshonly => true,
} 
}
}

I've done quite a bit of reading around this but can't quite figure out 
what I'm doing wrong.  When testing my array indexing via Ruby, things work 
fine so my thought is that this is a DSL thing that I've missed.  I've done 
some reading around future parser but I don't understand it enough to tell 
if that's my problem.  

If anybody could help shed some light on this one, I'd be most grateful. 
 This is similar to another of my posts', with the exception that before I 
wasn't using an array as a fact's value and thus, I'm quite confused.   
(Old Post: 
 https://groups.google.com/forum/#!topic/puppet-users/1ol4b1euTiE)

Both server and client are running:  Puppet 3.6.2/Facter 2.1.0

Thank you in advance for your help.

Cheers,

Mike



-- 
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/03753d71-b1c8-495e-8155-8b2be10526b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Referencing hash values within module

[Mike Reed]

Hey John,

Your comments make absolute sense and after making some changes, things are 
working as expected.  I've corrected my if statement to include the 'in' 
operator along with changing the syntax for how I'm retrieving the 
key/value pairs - ${model_hash[$::video_card_id]} - and that fixed things 
right up.

Your bonus comments are very helpful and I'll be making some changes based 
on your recommendations.  

Also, I wanted to thank you again - as always - for taking the time to not 
only explain the issue, but also for enlightening me on how I can make 
fundamental changes that will make my code better.  

Your help is very much appreciated.  

Cheers,

Mike 

On Friday, January 22, 2016 at 9:09:53 AM UTC-8, jcbollinger wrote:
>
>
> On Thursday, January 21, 2016 at 4:20:38 PM UTC-6, Mike Reed wrote:
>
> Hello all,
>>
>> I've got a module that I've been working on in an attempt to make things 
>> a little smarter and I figured using a hash would be an elegant solution to 
>> my problem.  The short story is that I've got various video cards in our 
>> production environment and I'd like to have a module that determines what 
>> driver will be installed, depending on the make of the card. 
>>
>> I've written some custom facts to help determine the class of the 
>> machine, what the video card id is and additionally, if the nvidia driver 
>> is currently installed.  These facts have been working fine for quite some 
>> time and I can check the values by running a facter -p, which results in 
>> something like:
>>
>> nvidia_installed => false
>> video_card_id => 17c2
>> class => workstation
>>
>> With that said, here's the module that I've written:
>>
>>  class nvidia::driver_install (
>>   
>>   $model_hash = {
>>   009d => "$::nvidia::params::quadro_fx_4500_driver",
>>   06dc => "$::nvidia::params::quadro_6000_driver",
>>   06d9 => "$::nvidia::params::quadro_5000_driver",
>>   11ba => "$::nvidia::params::quadro_K5000_driver",
>>   17c2 => "$::nvidia::params::gtx_titanx_driver",
>>   17f0 =>  "$::nvidia::params::quadro_M6000_driver",
>>   }
>>   
>> ) inherits nvidia::params {
>>
>>   if ($::is_virtual == true) and ($::class == 'server') {
>> notify { 'This is a virtual machine and the nvidia driver doesn\'t 
>> get intalled' : 
>>   }
>> # only run nvidia installer if the machine is a workstation and the 
>> driver is not already installed
>>   } elsif ($::class == 'workstation') and ($::nvidia_installed == 
>> 'false') {
>>   if ($::video_card_id == $model_hash[key]) {
>> notify { "Installing driver for ($model_hash[key])" : }
>> exec { 'kdm-stop' :
>>   command => '/usr/bin/service kdm stop' ,
>>   unless  => '/usr/bin/service kdm status | grep -i "stop" ' ,
>>   before  => Exec['nvidia-driver-install'] ,
>> }
>> # install nvidia driver
>> exec { 'nvidia-driver-install' :
>>   command => "/usr/src/($model_hash[value]).run -s -X -N 
>> --force-tls=new --no-x-check --no-cc-version-check" ,
>>   require => File["/usr/src/($model_hash[value]).run"] ,
>>   notify  => Exec['reboot_after_nvidia'] ,
>> }
>> # reboot after nvidia install
>> exec { 'reboot_after_nvidia' :
>>   command => "/sbin/reboot" ,
>>   refreshonly => true ,
>> }
>>   }
>>   }
>> }
>>
>> In addition, I've got most of my parameters saved into the 
>> ::nvidia::params.pp file of the module, which then points to hiera for its 
>> values:
>>
>> $quadro_fx_4500_driver   = hiera('nvidia::quadro_fx_4500_driver')
>> $quadro_6000_driver= hiera('nvidia::quadro_6000_driver')
>> $quadro_5000_driver= hiera('nvidia::quadro_5000_driver')
>> $quadro_K5000_driver = hiera('nvidia::quadro_K5000_driver')
>> $quadro_M6000_driver = hiera('nvidia::quadro_M6000_driver')
>> $gtx_titanx_driver= hiera('nvidia::gtx_titanx_driver')
>>
>> These values all resolve and if I use them by name (without the hash), 
>> things seem to work.
>>
>> My first question is, does it appear that my 

[Puppet Users] Re: Referencing hash values within module

[Mike Reed]

Hello Thomas,

Thank you for your comments and thoughts.  I'm still trying to understand 
basic programming and I see now that I'm mixing things up.  

I also wanted to thank you for taking the time to put the code up on gist, 
in order to give me a clear example of what you are talking about.  I very 
much appreciate it.

Cheers,

Mike

On Friday, January 22, 2016 at 1:11:38 AM UTC-8, Thomas Müller wrote:
>
> Hi Mike
>
> Am Donnerstag, 21. Januar 2016 23:20:38 UTC+1 schrieb Mike Reed:
>>
>> ... check the values by running a facter -p, which results in something 
>> like:
>>
>> nvidia_installed => false
>> video_card_id => 17c2
>> class => workstation
>>
>  
> ...
>  
>
>>
>>   if ($::is_virtual == true) and ($::class == 'server') {
>> notify { 'This is a virtual machine and the nvidia driver doesn\'t 
>> get intalled' : 
>>   }
>> # only run nvidia installer if the machine is a workstation and the 
>> driver is not already installed
>>   } elsif ($::class == 'workstation') and ($::nvidia_installed == 
>> 'false') {
>>
>  
>
>>   if ($::video_card_id == $model_hash[key]) {
>>
>
> What is key? key is a bare word not a variable. Maybe you meant "if 
> (!empty($model_hash[$::video_card_id])" ?
>
> https://gist.github.com/vinzent/5e5f187a8d1dcb000f8a/revisions
>  
>
>> notify { "Installing driver for ($model_hash[key])" : }
>> exec { 'kdm-stop' :
>>
>  
>
>> Also, as a bonus question, if I wanted to use this code in another 
>> module, is it as simple as "include ::nvidia::driver_install"?
>>
>
> it should be as easy as that.
>
> I do see some problems with the exec reboot. It will initiate the reboot 
> while puppet is applying changes. this might produce unexpected results.
>
> - Thomas
>

-- 
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/8e5fe5e2-722b-4c8a-be3c-5d7e0ae7aee0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Referencing hash values within module

[Mike Reed]

Hello all,

I've got a module that I've been working on in an attempt to make things a 
little smarter and I figured using a hash would be an elegant solution to 
my problem.  The short story is that I've got various video cards in our 
production environment and I'd like to have a module that determines what 
driver will be installed, depending on the make of the card. 

I've written some custom facts to help determine the class of the machine, 
what the video card id is and additionally, if the nvidia driver is 
currently installed.  These facts have been working fine for quite some 
time and I can check the values by running a facter -p, which results in 
something like:

nvidia_installed => false
video_card_id => 17c2
class => workstation

With that said, here's the module that I've written:

 class nvidia::driver_install (
  
  $model_hash = {
  009d => "$::nvidia::params::quadro_fx_4500_driver",
  06dc => "$::nvidia::params::quadro_6000_driver",
  06d9 => "$::nvidia::params::quadro_5000_driver",
  11ba => "$::nvidia::params::quadro_K5000_driver",
  17c2 => "$::nvidia::params::gtx_titanx_driver",
  17f0 =>  "$::nvidia::params::quadro_M6000_driver",
  }
  
) inherits nvidia::params {

  if ($::is_virtual == true) and ($::class == 'server') {
notify { 'This is a virtual machine and the nvidia driver doesn\'t get 
intalled' : 
  }
# only run nvidia installer if the machine is a workstation and the 
driver is not already installed
  } elsif ($::class == 'workstation') and ($::nvidia_installed == 'false') {
  if ($::video_card_id == $model_hash[key]) {
notify { "Installing driver for ($model_hash[key])" : }
exec { 'kdm-stop' :
  command => '/usr/bin/service kdm stop' ,
  unless  => '/usr/bin/service kdm status | grep -i "stop" ' ,
  before  => Exec['nvidia-driver-install'] ,
}
# install nvidia driver
exec { 'nvidia-driver-install' :
  command => "/usr/src/($model_hash[value]).run -s -X -N 
--force-tls=new --no-x-check --no-cc-version-check" ,
  require => File["/usr/src/($model_hash[value]).run"] ,
  notify  => Exec['reboot_after_nvidia'] ,
}
# reboot after nvidia install
exec { 'reboot_after_nvidia' :
  command => "/sbin/reboot" ,
  refreshonly => true ,
}
  }
  }
}

In addition, I've got most of my parameters saved into the 
::nvidia::params.pp file of the module, which then points to hiera for its 
values:

$quadro_fx_4500_driver   = hiera('nvidia::quadro_fx_4500_driver')
$quadro_6000_driver= hiera('nvidia::quadro_6000_driver')
$quadro_5000_driver= hiera('nvidia::quadro_5000_driver')
$quadro_K5000_driver = hiera('nvidia::quadro_K5000_driver')
$quadro_M6000_driver = hiera('nvidia::quadro_M6000_driver')
$gtx_titanx_driver= hiera('nvidia::gtx_titanx_driver')

These values all resolve and if I use them by name (without the hash), 
things seem to work.

My first question is, does it appear that my logic is correct?  After 
reading the puppet docs about data types and hashes in particular, it 
appears to me that I've got the correct syntax.  With the above module in 
place, I can run a puppet job; but nothing ever gets applied to the host 
(no errors are ever reported and the jobs completes successfully).  This 
leads me to believe that I'm using the hash incorrectly and because of 
that, values aren't being determined and therefore this particular piece of 
the module doesn't get applied.  Might you have any thoughts on why this 
doesn't appear to work?

Also, as a bonus question, if I wanted to use this code in another module, 
is it as simple as "include ::nvidia::driver_install"?

Thank you in advance to everybody for your help and your assistance.  Your 
help is very much appreciated.

Cheers,

Mike

-- 
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/cfbdb396-0f91-4950-a161-a4e1c52eefe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Facter - custom fact regex

[Mike Reed]

That is a great idea and I'll get that changed to something else.

Cheers,

Mike

On Thursday, January 14, 2016 at 10:23:06 AM UTC-8, Thomas Müller wrote:
>
> IMHO the fact "network" is a default fact from facter >= 3. i would change 
> the name.
>

-- 
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/04bddc6a-0b09-4c41-8675-46d63ce8910e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Facter - custom fact regex

[Mike Reed]

Thank you for the info John.  I did fix the typo and it looks like the fact 
wasn't sync'd correctly to the client.  It's all fixed up now and working 
as expected.

You've always been a great help and I very much appreciate your time.

Let me know where to send the six pack.

Cheers,

Mike

On Wednesday, January 13, 2016 at 6:31:20 AM UTC-8, jcbollinger wrote:
>
>
>
> On Tuesday, January 12, 2016 at 5:42:45 PM UTC-6, Mike Reed wrote:
>>
>> Hello all,
>>
>> I'm having some trouble with a custom fact and I was hoping somebody 
>> could tell me what I'm doing wrong.  
>>
>> Here is an example of the code:
>>
>> require 'facter'
>> Facter.add('network') do
>>   setcode do
>> hostname = Facter.value(:hostname)
>> ipaddress = Facter.value(:ipaddress)
>> case 
>>   when 
>> ipaddres.match(/^(\d[10]\.)(\d[10]\.)([1][2][7]\.)([1-9][1-9][1-9])?/)
>> network = 'net1'  
>>   when hostname.match(/^nettwo/)
>> network = 'net2'
>>   when hostname.match(/^netthree/)
>> network = 'net3'
>>   when hostname.match(/^netfour/)
>> network = 'net4'
>>   else
>> network = 'nonet'
>>   end
>> network
>> end
>> end
>>
>> I've gotten myself into a pickle in that most hosts have a hostname 
>> prefix to designate what network they are on.  In this case, I don't have a 
>> prefix but the physical ip is different and my thoughts were to regex match 
>> the ip address and bingo...but no luck.
>>
>> Puppet runs and pluginsync does pull down the fact but I never get the 
>> value of network back.   No errors are displayed or logged when running 
>> 'facter -p' but again, I never get the value of network back.  I've done 
>> quite a bit of reading and can't figure out why this one doesn't work.
>>
>
>
> You misspell "ipaddress" in the first "when" clause.  I wouldn't have 
> expected that to cause the fact to be silently ignored, and maybe it 
> doesn't, but you should fix it regardless.
>
> Otherwise, I don't see anything inherently wrong with your fact code.  If 
> after you fix the misspelling, the fact is not submitted to the master, and 
> 'facter -p' neither prints it nor emits any error message, then my first 
> guess would be that it has not properly been synced, your assertion to the 
> contrary notwithstanding.  In that case, look into where the synced file 
> actually went (if anywhere).  If it is indeed in a subdirectory "facter" of 
> some directory in the Ruby load path, then verify that the file and every 
> directory in the path to it is accessible to puppet and facter.  Even with 
> the agent running with privilege, as normally it must do, it is possible 
> for it to be denied access to some files and directories.
>
>
> 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/87f28dbb-00c3-420f-9985-123c38c8c2c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facter - custom fact regex

[Mike Reed]

Hey Hristo,

This did not work for me but I wanted to thank you for the info.  It turns 
out the fact wasn't being sync'd correctly to the client and therefore not 
all my changes were being reflected locally.

Thank you again for the info. 

Cheers,

Mike.

On Wednesday, January 13, 2016 at 3:26:18 AM UTC-8, Hristo Mohamed wrote:
>
> Try :
> setcode { network }
>
> From puppett docs:
>
>
>1. A call to Facter.add('fact_name'), which determines the name of the 
>fact
>2. A setcode statement for simple resolutions, which is evaluated to 
>determine the fact’s value.
>
>
> On Wed, Jan 13, 2016 at 12:42 AM, Mike Reed  > wrote:
>
>> Hello all,
>>
>> I'm having some trouble with a custom fact and I was hoping somebody 
>> could tell me what I'm doing wrong.  
>>
>> Here is an example of the code:
>>
>> require 'facter'
>> Facter.add('network') do
>>   setcode do
>> hostname = Facter.value(:hostname)
>> ipaddress = Facter.value(:ipaddress)
>> case 
>>   when 
>> ipaddres.match(/^(\d[10]\.)(\d[10]\.)([1][2][7]\.)([1-9][1-9][1-9])?/)
>> network = 'net1'  
>>   when hostname.match(/^nettwo/)
>> network = 'net2'
>>   when hostname.match(/^netthree/)
>> network = 'net3'
>>   when hostname.match(/^netfour/)
>> network = 'net4'
>>   else
>> network = 'nonet'
>>   end
>> network
>> end
>> end
>>
>> I've gotten myself into a pickle in that most hosts have a hostname 
>> prefix to designate what network they are on.  In this case, I don't have a 
>> prefix but the physical ip is different and my thoughts were to regex match 
>> the ip address and bingo...but no luck.
>>
>> Puppet runs and pluginsync does pull down the fact but I never get the 
>> value of network back.   No errors are displayed or logged when running 
>> 'facter -p' but again, I never get the value of network back.  I've done 
>> quite a bit of reading and can't figure out why this one doesn't work.  
>>
>> Does anybody perhaps have any suggestions as to how I might accomplish 
>> this?
>>
>> Thank you in advance for your assistance.
>>
>> Cheers,
>>
>> Mike
>>
>> -- 
>> 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/cbf9ea68-fffd-4e14-a467-486d8832bc0e%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/cbf9ea68-fffd-4e14-a467-486d8832bc0e%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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4d44092b-6b1f-4999-8a52-c7b0b41a5150%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Facter - custom fact regex

[Mike Reed]

Hello all,

I'm having some trouble with a custom fact and I was hoping somebody could 
tell me what I'm doing wrong.  

Here is an example of the code:

require 'facter'
Facter.add('network') do
  setcode do
hostname = Facter.value(:hostname)
ipaddress = Facter.value(:ipaddress)
case 
  when 
ipaddres.match(/^(\d[10]\.)(\d[10]\.)([1][2][7]\.)([1-9][1-9][1-9])?/)
network = 'net1'  
  when hostname.match(/^nettwo/)
network = 'net2'
  when hostname.match(/^netthree/)
network = 'net3'
  when hostname.match(/^netfour/)
network = 'net4'
  else
network = 'nonet'
  end
network
end
end

I've gotten myself into a pickle in that most hosts have a hostname prefix 
to designate what network they are on.  In this case, I don't have a prefix 
but the physical ip is different and my thoughts were to regex match the ip 
address and bingo...but no luck.

Puppet runs and pluginsync does pull down the fact but I never get the 
value of network back.   No errors are displayed or logged when running 
'facter -p' but again, I never get the value of network back.  I've done 
quite a bit of reading and can't figure out why this one doesn't work.  

Does anybody perhaps have any suggestions as to how I might accomplish this?

Thank you in advance for your assistance.

Cheers,

Mike

-- 
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/cbf9ea68-fffd-4e14-a467-486d8832bc0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] String/Float comparison - Puppet and Facter

[Mike Reed]

Thanks you Martin, that is exactly what I needed.

Cheers,

m.

On Monday, August 3, 2015 at 11:07:09 PM UTC-7, Martin Alfke wrote:
>
>
> On 04 Aug 2015, at 00:39, Mike Reed > 
> wrote: 
>
> > Hello all, 
> > 
> > I've been trying to solve what seems to be a simple problem but have yet 
> to find the answer.   
> > 
> > I'm trying to do a comparison between the value of a fact and some 
> arbitrary value: 
> > 
> > if ($::class == 'workstation') and ($::kernelmajversion <= '3.11') { 
>
> You compare two strings. 
> Have you tried versioncmp function instead? 
> versioncmp($::kernelmajversion, ‘3.11’) 
>
> https://docs.puppetlabs.com/references/latest/function.html#versioncmp 
>
>
> > notify {"My Kernel version is <= ${kernel_test_version} and I'm 
> going to upgrade" : } 
> > 
> > file { 
> "/usr/src/linux-headers-${kernel_test_version}_${kernel_release_test_version}~precise1_all.deb"
>  
> : 
> >   mode   => '755', 
> >   ensure => 'present', 
> >   source => 
> "puppet:///modules/kernel/${kernel_test_version}_${kernel_release_test_version}~precise1_all.deb"
>  
>
> >  } 
> >   } 
> >   
> >   elsif ($::class == 'workstation') and ($::kernelmajversion >= '3.11') 
> { 
> > notify {"My Kernel version is >= ${kernel_test_version} so I don't 
> need to upgrade": } 
> >   } 
> > 
> > 
> > After invoking a puppet run, I can never get the evaluation of "if" to 
> actually take place and as a result, the elsif is invoked and regardless of 
> whether or not the kernel version is <= 3.11, the "if" statement is never 
> run.  From what I gather, this means that the evaluation of "if" is never 
> happening and the resulting elsif is automatically invoked. 
> > 
> > I've also seen some errors that pertain to string/float comparisons and 
> to my knowledge, facter data is coming back as a string and my version 
> number in the "if" statement (3.11) is a float and therefore can't be 
> compared due to comparison rules of different data types. 
> > 
> > Does anybody have some words of wisdom that may lead me to the correct 
> syntax for what I'm trying to achieve? 
> > 
> > Thanks in advance to the community for the help. 
> > 
> > Cheers, 
> > 
> > Mike 
> > 
> > 
> > 
> > -- 
> > 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/5f9249a2-1bab-4f7e-84b5-f5fa6afd3ad7%40googlegroups.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/7f1bfdb8-c1c5-4c9c-b7e8-d932425d700f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] String/Float comparison - Puppet and Facter

[Mike Reed]

Hello all,

I've been trying to solve what seems to be a simple problem but have yet to 
find the answer.  

I'm trying to do a comparison between the value of a fact and some 
arbitrary value:

if ($::class == 'workstation') and ($::kernelmajversion <= '3.11') {
notify {"My Kernel version is <= ${kernel_test_version} and I'm going 
to upgrade" : }

file { 
"/usr/src/linux-headers-${kernel_test_version}_${kernel_release_test_version}~precise1_all.deb"
 
:
  mode   => '755',
  ensure => 'present',
  source => 
"puppet:///modules/kernel/${kernel_test_version}_${kernel_release_test_version}~precise1_all.deb"
 }
  }
  
  elsif ($::class == 'workstation') and ($::kernelmajversion >= '3.11') {
notify {"My Kernel version is >= ${kernel_test_version} so I don't need 
to upgrade": }
  }


After invoking a puppet run, I can never get the evaluation of "if" to 
actually take place and as a result, the elsif is invoked and regardless of 
whether or not the kernel version is <= 3.11, the "if" statement is never 
run.  From what I gather, this means that the evaluation of "if" is never 
happening and the resulting elsif is automatically invoked.

I've also seen some errors that pertain to string/float comparisons and to 
my knowledge, facter data is coming back as a string and my version number 
in the "if" statement (3.11) is a float and therefore can't be compared due 
to comparison rules of different data types.

Does anybody have some words of wisdom that may lead me to the correct 
syntax for what I'm trying to achieve?

Thanks in advance to the community for the help.

Cheers,

Mike


-- 
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/5f9249a2-1bab-4f7e-84b5-f5fa6afd3ad7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: subscribe and refreshonly - expected behavior

[Mike Reed]

Hey John,

Thank you for the info on this one.  I never even considered the sync and 
your answer provides some great insight.

Thanks again,

m.

On Wednesday, October 1, 2014 11:57:04 AM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> My thanks in advance to anybody with thoughts on this.  I have a module in 
> which I would like two resources to be applied/refreshed based on the 
> change of their parent resource.  
>
> The code looks something like this:
>
> exec {'assume_default_domain':
>   command => "${pbis_bin_path}/config AssumeDefaultDomain true",
>   subscribe   => Exec['create_home_dir'],
>   refreshonly => true,
> }
> 
> exec {'user_domain_prefix':
>   command => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
>   subscribe   => Exec['assume_default_domain'],
> }
>
> When running a 'puppet agent -tvd' I get the following:
>
> Notice: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Triggered 
> 'refresh' from 1 events
> Info: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Scheduling 
> refresh of Exec[user_domain_prefix]
> Debug: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: The 
> container Class[Pbis::Config] will propagate my refresh event
> Debug: Exec[user_domain_prefix](provider=posix): Executing 
> '/opt/pbis/bin/config UserDomainPrefix "" '
> Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
> Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]/returns: 
> executed successfully
> Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container 
> Class[Pbis::Config] will propagate my refresh event
> Debug: Exec[user_domain_prefix](provider=posix): Executing 
> '/opt/pbis/bin/config UserDomainPrefix "" '
> Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
> Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: Triggered 
> 'refresh' from 1 events
> Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container 
> Class[Pbis::Config] will propagate my refresh event
> Debug: Class[Pbis::Config]: The container Stage[main] will propagate my 
> refresh event
> Debug: Class[Pbis::Config]: The container Class[Pbis] will propagate my 
> refresh event
> Debug: Class[Pbis]: The container Stage[main] will propagate my refresh 
> event
> Debug: Finishing transaction 25871380
> Debug: Storing state
> Debug: Stored state in 0.06 seconds
>
> As you can see, the 'user_domain_prefix' resource is firing twice and I'm 
> not sure why.  If I change the resource and add a 'refreshonly', I get the 
> desired result (resource only being applied once):
>
> exec {'user_domain_prefix':
>   command => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
>   subscribe   => Exec['assume_default_domain'],
>   refreshonly => true,
>
> Notice: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Triggered 
> 'refresh' from 1 events
> Info: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Scheduling 
> refresh of Exec[user_domain_prefix]
> Debug: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: The 
> container Class[Pbis::Config] will propagate my refresh event
> Debug: Exec[user_domain_prefix](provider=posix): Executing 
> '/opt/pbis/bin/config UserDomainPrefix "" '
> Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
> Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: Triggered 
> 'refresh' from 1 events
> Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container 
> Class[Pbis::Config] will propagate my refresh event
> Debug: Class[Pbis::Config]: The container Stage[main] will propagate my 
> refresh event
> Debug: Class[Pbis::Config]: The container Class[Pbis] will propagate my 
> refresh event
> Debug: Class[Pbis]: The container Stage[main] will propagate my refresh 
> event
> Debug: Finishing transaction 29272600
> Debug: Storing state
> Debug: Stored state in 0.06 seconds
>
> My understanding is that 'subscribe' will both create a dependency and 
> will require the refreshing of the dependent object, based on the 
> subscribed objects' state.  I also understand 'refreshonly' to be a 
> mechanism used when a dependent object is changed (sounds almost the same 
> as subscribe except it doesn't create a dependency).  Based on my example 
> above, I would expect 'subscribe' alone to satisfy my needs and I don

[Puppet Users] subscribe and refreshonly - expected behavior

[Mike Reed]

Hello all,

My thanks in advance to anybody with thoughts on this.  I have a module in 
which I would like two resources to be applied/refreshed based on the 
change of their parent resource.  

The code looks something like this:

exec {'assume_default_domain':
  command => "${pbis_bin_path}/config AssumeDefaultDomain true",
  subscribe   => Exec['create_home_dir'],
  refreshonly => true,
}

exec {'user_domain_prefix':
  command => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
  subscribe   => Exec['assume_default_domain'],
}

When running a 'puppet agent -tvd' I get the following:

Notice: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Triggered 
'refresh' from 1 events
Info: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Scheduling 
refresh of Exec[user_domain_prefix]
Debug: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: The container 
Class[Pbis::Config] will propagate my refresh event
Debug: Exec[user_domain_prefix](provider=posix): Executing 
'/opt/pbis/bin/config UserDomainPrefix "" '
Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]/returns: 
executed successfully
Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container 
Class[Pbis::Config] will propagate my refresh event
Debug: Exec[user_domain_prefix](provider=posix): Executing 
'/opt/pbis/bin/config UserDomainPrefix "" '
Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: Triggered 
'refresh' from 1 events
Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container 
Class[Pbis::Config] will propagate my refresh event
Debug: Class[Pbis::Config]: The container Stage[main] will propagate my 
refresh event
Debug: Class[Pbis::Config]: The container Class[Pbis] will propagate my 
refresh event
Debug: Class[Pbis]: The container Stage[main] will propagate my refresh 
event
Debug: Finishing transaction 25871380
Debug: Storing state
Debug: Stored state in 0.06 seconds

As you can see, the 'user_domain_prefix' resource is firing twice and I'm 
not sure why.  If I change the resource and add a 'refreshonly', I get the 
desired result (resource only being applied once):

exec {'user_domain_prefix':
  command => "${pbis_bin_path}/config UserDomainPrefix \"\" ",
  subscribe   => Exec['assume_default_domain'],
  refreshonly => true,

Notice: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Triggered 
'refresh' from 1 events
Info: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: Scheduling 
refresh of Exec[user_domain_prefix]
Debug: /Stage[main]/Pbis::Config/Exec[assume_default_domain]: The container 
Class[Pbis::Config] will propagate my refresh event
Debug: Exec[user_domain_prefix](provider=posix): Executing 
'/opt/pbis/bin/config UserDomainPrefix "" '
Debug: Executing '/opt/pbis/bin/config UserDomainPrefix "" '
Notice: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: Triggered 
'refresh' from 1 events
Debug: /Stage[main]/Pbis::Config/Exec[user_domain_prefix]: The container 
Class[Pbis::Config] will propagate my refresh event
Debug: Class[Pbis::Config]: The container Stage[main] will propagate my 
refresh event
Debug: Class[Pbis::Config]: The container Class[Pbis] will propagate my 
refresh event
Debug: Class[Pbis]: The container Stage[main] will propagate my refresh 
event
Debug: Finishing transaction 29272600
Debug: Storing state
Debug: Stored state in 0.06 seconds

My understanding is that 'subscribe' will both create a dependency and will 
require the refreshing of the dependent object, based on the subscribed 
objects' state.  I also understand 'refreshonly' to be a mechanism used 
when a dependent object is changed (sounds almost the same as subscribe 
except it doesn't create a dependency).  Based on my example above, I would 
expect 'subscribe' alone to satisfy my needs and I don't understand why I 
get duplicate refresh events when something is simply 'subscribed' but only 
one refresh event when a resource is set to both 'subscribe' and 
'refreshonly'.

Would anybody have a quick explanation for this one?

Thanks again for your help in advance.

Cheers,

Mike

-- 
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/adad7980-adc0-48eb-8ffa-d3b151f4a911%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: class/subclass relationship ordering and containment

[Mike Reed]

Hey John,

Thanks for the reply and comments to my questions.  I understand what 
you're saying and the ideas of include/inherit/contain make better sense 
now.

Cheers,

Mike.

On Friday, September 19, 2014 4:01:28 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I have a question about class and subclass relationships and what is/isn't 
> the ideal way to go about such a thing.  Please bear with me  as I'm still 
> refining my understanding of containment. Let's say I have a puppet module 
> which manages the install of puppet and has the following pieces (currently 
> using puppet v.3.4.3):
>
> *init.pp*
> class puppet {
>   # evaluate supporting classes
>   include puppet::params
>   include puppet::config
>   include puppet::service
>   
>   anchor { 'puppet::begin' : } ->
>   class { '::puppet::params' : } ->
>   class { '::puppet::config' : } ~>
>   class { '::puppet::service' : } ->
>   anchor { 'puppet::end' : }
> }
>
> *params.pp*
> class puppet::params {
> # puppet general params
>   $puppet_path= '/etc/puppet'
>   $puppet_config_template = 'puppet/puppet.conf.erb'
>   $puppet_package = 'puppet'
>   $puppet_common_package  = 'puppet-common'
>   $puppet_service_ensure  = 'running'
>   $puppet_service_enable  = true
>   $puppet_prod_version= '3.6.2-1puppetlabs1'
>   $puppet_dev_version = '3.6.2-1puppetlabs1'
>   validate_string($puppet_path)
>   validate_string($puppet_config_template)
>   validate_string($puppet_package)
>   validate_string($puppet_common_package)
>   validate_string($puppet_service_ensure)
>   validate_bool($puppet_service_enable)
>   validate_string($puppet_prod_version)
>   validate_string($puppet_dev_version)
> }
>
> *config.pp*
> class puppet::config (
>
>   $puppet_config_path = $::puppet::params::puppet_config_path,
>   $puppet_config_template = $::puppet::params::puppet_config_template,
>   $puppet_service = $::puppet::params::puppet_service,
>   
> ) inherits puppet::params {
>
>   file { 'puppet.conf' :
> ensure  => present,
> path=> "${puppet_config_path}/",
> content => template("${puppet_config_template}"),
> notify  => Service["${puppet_service}"],
>   }
> }
>
> *service.pp*
> class puppet::service (
>
>   $puppet_package = $::puppet::params::puppet_package,
> ***truncated variables for sake of a long post***
>
> ) inherits puppet::config { 
>
>   package { "${puppet_package}":
> ensure  => "${puppet_prod_version}",
>   }
>
>   package { "${puppet_common_package}":
> ensure  => "${puppet_prod_version}",
>   }
>
>   service { "${puppet_service}":
> ensure => "${puppet_service_ensure}",
> name   => "${puppet_service}",
> enable => "${puppet_service_enable}",
> hasrestart => true,
> hasstatus  => true,
> subscribe  => Package["${puppet_config_template}"],
>   }
> }
>
> Based on the above, I've left a few things which I feel don't belong but 
> for the sake of my questions, they're included.
>
> Per the above init.pp, I've added an anchor to force ordering.  My 
> understanding is that this has nothing to do with application-order and 
> more to do with parse-order.  With that said, I have a few questions:
>
> 1.  By adding the 'include' in init.pp, my understanding is that simply 
> says to 'evaluate' the subclasses but does not indicate an order to which 
> subclasses are to be applied.  Is that correct?
>
> 2.  I think the 'inherits' function is depreciated but should each 
> instance be replaced with a 'contain' (based on the order I want) 
> throughout my subclass manifests?  My understanding is that I should never 
> 'contain' more than one subclass within the same module as puppet will be 
> confused on ordering.
>
> 3.  I rather like the idea of the anchor in the init.pp because I only 
> have one place to go to, in order to see the relationship of the 
> subclasses. With the introduction of the 'contain' feature, I feel like the 
> anchor is no longer needed; however, is there a preferred way of ordering 
> these subclasses without using the anchor pattern?
>
> As always, thanks in advance for your help.
>
> Cheers,
>
> Mike
>
>   
>
>
>

-- 
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/606a40dd-fa7e-493a-8dc9-b860cd91f732%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: class/subclass relationship ordering and containment

[Mike Reed]

Hey Nan and John,

Thank you both for the replies and insight into my questions below; they 
are most helpful and very much appreciated.

Based on your answers, I have few other questions that occurred to me:

In response to my question about inherits, John had mentioned this below: 
"If you don't need the variables of the params class for class parameter 
defaults, however, then you can replace inheritance with 'include'ing (or 
'require'ing or 'contain'ing) the params class it the start of erstwhile 
child class's body."

In my example config.pp, I'm using things like "$puppet_config_path = 
$::puppet::params::puppet_config_path," which obviously points to my 
params.pp file and thus would in theory, pull the variable value and 
evaluate accordingly.  If I am indeed pointing these local variables to my 
params.pp, it doesn't seem obvious that I need any include or inhert to 
params.pp in my subclasses.  In this example, I do indeed need the 
variables from my params class for my subclass defaults but because I'm 
specifically calling these with the use of local variables, is it advisable 
to still "include" the params.pp subclass?  It seems that my manifests 
would be more tidy if I didn't have include/inherits littered throughout my 
subclasses.

Further, if I had a selector or case statement in my params.pp, they it 
would seem appropriate to "include" params.pp in my config.pp because I 
indeed do need that selector/case statement to be evaluated before the 
config.pp subclass can be completed.  Am I thinking about this correctly?

Lastly, it seems that in the case of any module with subclasses, I want and 
need to include class/subclass ordering or the sake of ordering sanity.  In 
your opinion, should I be including subclass ordering in my init.pp for 
each module I write (assuming it includes subclasses)?  

Thank you guys for your invaluable information and for you patience.

Cheers,

Mike



On Friday, September 19, 2014 4:01:28 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I have a question about class and subclass relationships and what is/isn't 
> the ideal way to go about such a thing.  Please bear with me  as I'm still 
> refining my understanding of containment. Let's say I have a puppet module 
> which manages the install of puppet and has the following pieces (currently 
> using puppet v.3.4.3):
>
> *init.pp*
> class puppet {
>   # evaluate supporting classes
>   include puppet::params
>   include puppet::config
>   include puppet::service
>   
>   anchor { 'puppet::begin' : } ->
>   class { '::puppet::params' : } ->
>   class { '::puppet::config' : } ~>
>   class { '::puppet::service' : } ->
>   anchor { 'puppet::end' : }
> }
>
> *params.pp*
> class puppet::params {
> # puppet general params
>   $puppet_path= '/etc/puppet'
>   $puppet_config_template = 'puppet/puppet.conf.erb'
>   $puppet_package = 'puppet'
>   $puppet_common_package  = 'puppet-common'
>   $puppet_service_ensure  = 'running'
>   $puppet_service_enable  = true
>   $puppet_prod_version= '3.6.2-1puppetlabs1'
>   $puppet_dev_version = '3.6.2-1puppetlabs1'
>   validate_string($puppet_path)
>   validate_string($puppet_config_template)
>   validate_string($puppet_package)
>   validate_string($puppet_common_package)
>   validate_string($puppet_service_ensure)
>   validate_bool($puppet_service_enable)
>   validate_string($puppet_prod_version)
>   validate_string($puppet_dev_version)
> }
>
> *config.pp*
> class puppet::config (
>
>   $puppet_config_path = $::puppet::params::puppet_config_path,
>   $puppet_config_template = $::puppet::params::puppet_config_template,
>   $puppet_service = $::puppet::params::puppet_service,
>   
> ) inherits puppet::params {
>
>   file { 'puppet.conf' :
> ensure  => present,
> path=> "${puppet_config_path}/",
> content => template("${puppet_config_template}"),
> notify  => Service["${puppet_service}"],
>   }
> }
>
> *service.pp*
> class puppet::service (
>
>   $puppet_package = $::puppet::params::puppet_package,
> ***truncated variables for sake of a long post***
>
> ) inherits puppet::config { 
>
>   package { "${puppet_package}":
> ensure  => "${puppet_prod_version}",
>   }
>
>   package { "${puppet_common_package}":
> ensure  => "${puppet_prod_version}",
>   }
>
>   service { "${puppet_service}":
> ensure => "${puppet_serv

[Puppet Users] class/subclass relationship ordering and containment

[Mike Reed]

Hello all,

I have a question about class and subclass relationships and what is/isn't 
the ideal way to go about such a thing.  Please bear with me  as I'm still 
refining my understanding of containment. Let's say I have a puppet module 
which manages the install of puppet and has the following pieces (currently 
using puppet v.3.4.3):

*init.pp*
class puppet {
  # evaluate supporting classes
  include puppet::params
  include puppet::config
  include puppet::service
  
  anchor { 'puppet::begin' : } ->
  class { '::puppet::params' : } ->
  class { '::puppet::config' : } ~>
  class { '::puppet::service' : } ->
  anchor { 'puppet::end' : }
}

*params.pp*
class puppet::params {
# puppet general params
  $puppet_path= '/etc/puppet'
  $puppet_config_template = 'puppet/puppet.conf.erb'
  $puppet_package = 'puppet'
  $puppet_common_package  = 'puppet-common'
  $puppet_service_ensure  = 'running'
  $puppet_service_enable  = true
  $puppet_prod_version= '3.6.2-1puppetlabs1'
  $puppet_dev_version = '3.6.2-1puppetlabs1'
  validate_string($puppet_path)
  validate_string($puppet_config_template)
  validate_string($puppet_package)
  validate_string($puppet_common_package)
  validate_string($puppet_service_ensure)
  validate_bool($puppet_service_enable)
  validate_string($puppet_prod_version)
  validate_string($puppet_dev_version)
}

*config.pp*
class puppet::config (

  $puppet_config_path = $::puppet::params::puppet_config_path,
  $puppet_config_template = $::puppet::params::puppet_config_template,
  $puppet_service = $::puppet::params::puppet_service,
  
) inherits puppet::params {

  file { 'puppet.conf' :
ensure  => present,
path=> "${puppet_config_path}/",
content => template("${puppet_config_template}"),
notify  => Service["${puppet_service}"],
  }
}

*service.pp*
class puppet::service (

  $puppet_package = $::puppet::params::puppet_package,
***truncated variables for sake of a long post***

) inherits puppet::config { 

  package { "${puppet_package}":
ensure  => "${puppet_prod_version}",
  }

  package { "${puppet_common_package}":
ensure  => "${puppet_prod_version}",
  }

  service { "${puppet_service}":
ensure => "${puppet_service_ensure}",
name   => "${puppet_service}",
enable => "${puppet_service_enable}",
hasrestart => true,
hasstatus  => true,
subscribe  => Package["${puppet_config_template}"],
  }
}

Based on the above, I've left a few things which I feel don't belong but 
for the sake of my questions, they're included.

Per the above init.pp, I've added an anchor to force ordering.  My 
understanding is that this has nothing to do with application-order and 
more to do with parse-order.  With that said, I have a few questions:

1.  By adding the 'include' in init.pp, my understanding is that simply 
says to 'evaluate' the subclasses but does not indicate an order to which 
subclasses are to be applied.  Is that correct?

2.  I think the 'inherits' function is depreciated but should each instance 
be replaced with a 'contain' (based on the order I want) throughout my 
subclass manifests?  My understanding is that I should never 'contain' more 
than one subclass within the same module as puppet will be confused on 
ordering.

3.  I rather like the idea of the anchor in the init.pp because I only have 
one place to go to, in order to see the relationship of the subclasses. 
With the introduction of the 'contain' feature, I feel like the anchor is 
no longer needed; however, is there a preferred way of ordering these 
subclasses without using the anchor pattern?

As always, thanks in advance for your help.

Cheers,

Mike

  


-- 
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/daeb1827-7d94-4921-ae09-31f2ea480e9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] hiera - default parameter values and design questions

[Mike Reed]

@Xav, thanks for the information and pointers.  I've added the 'default' 
value into my arrays and things are running smoothly now.  I'm still a bit 
hazy on the resource ordering and how hiera by default, deals with applying 
resources within (for example) a hiera.yaml file but for now, I have enough 
into to get on with.

Thanks again for your info and your time.

Cheers,

m.

On Thursday, September 11, 2014 7:11:21 PM UTC-7, Xav Paice wrote:
>
>  inline
>
> On 12/09/14 13:36, Mike Reed wrote:
>  
> Hello all,
>
> I ran into a problem with hiera and in particular, assigning or not 
> assigning default values to variables within a data source.  I'm using the 
> mcollective module (currently using version 1.1.6) and I've built a very 
> simple hiera backend to start adding site-specific data into a single 
> place.  Within the mcollective init.pp manifest, I've identified four 
> places for which I'd like to abstract data into hiera; they are:
>
> $server= hiera('::mcollective::server'),
> $client = hiera('::mcollective::client'),
> $middleware = hiera('::mcollective::middleware'),
> $middleware_hosts = hiera('::mcollective::middleware_hosts'),
>
> I've created a fqdn specific hiera source (ourlocalhost.local.yaml) and 
> added this:
>
> classes: 
>   - mcollective
>
> # mcollective parameters
> mcollective::middleware: true
> mcollective::server: true
> mcollective::client: true
> mcollective::middleware_hosts:
>   - ourlocalhost.local
>
> Upon running puppet on this specific host, the puppet run completes and I 
> marvel at the wonder of puppet and heiras' beautiful co-existence.
>
> Now I'd like to simply add mcollective to any node in my network so I go 
> to common.yaml and add the following:
>
> classes:
>   - mcollective
>
> # mcollective parameters
> mcollective::server: true
> mcollective::middleware_hosts:
>   - outlocalhost.local
>
> However, upon running puppet on a fresh machine, I get the following error:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Could not find data item ::mcollective::client in any Hiera data file and 
> no default supplied at 
> /etc/puppet/environments/test/modules/mcollective/manifests/init.pp:5 on 
> node mynode.local
>
> If I add this line into common.yaml (mcollective::client: false) then I 
> get the following failure:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Could not find data item ::mcollective::middleware in any Hiera data file 
> and no default supplied at 
> /etc/puppet/environments/test/modules/mcollective/manifests/init.pp:6 on 
> node mynode.local
>
> If I then go back into common.yaml and add 'false' to the values I don't 
> want, everything works:
>
> classes: mcollective
> mcollective::middleware: false
> mcollective::server: true
> mcollective::client: false
> mcollective::middleware_hosts:
>   - ourlocalhost.local
>
>
> I've been searching for answers on the interwebs and haven't been able to 
> find anything specific for this one so I figured I'd ask a few questions:
>
> 1.  Is this the expected functionality?  If so, am I to understand that I 
> have to keep track of every hiera call (ex $server = 
> hiera('::mcollective::server'), $client = hiera('::mcollective::client')), 
> in my many modules and create defaults for each of these values in the 
> various hiera source files that I create?  My understanding was that I 
> could create these hiera calls in my classes and a al carte these values 
> within my hiera source files.  Am I mistaken and if not, doesn't that 
> create redundant data within my hiera source file tree?  Also, if future-me 
> adds one additional hiera call to the init.pp, does that mean I have to 
> track down every hiera data source and add a default value to each one?  
>
>   
> There's two approaches to hiera - if you want to use the hiera() function, 
> you can give it two args - hiera('::mcollective::client', false) would look 
> at the content of ::mcollective::client and if there's nothing in hiera, 
> would return a default of false.  That's probably the simplest approach for 
> this example.
>
> Also be aware that you don't have to use the hiera() function in 
> parameterized classes (although it's nice and clear coding to do so).  You 
> could, for example, declare a class like so:
>
> class myclass (
>   $param1 = 'defaultvalue'
> ) {
>   codeblock
> }
>
> This would give $param1 a default value of 'defaultvalue'

[Puppet Users] hiera - default parameter values and design questions

[Mike Reed]

Hello all,

I ran into a problem with hiera and in particular, assigning or not 
assigning default values to variables within a data source.  I'm using the 
mcollective module (currently using version 1.1.6) and I've built a very 
simple hiera backend to start adding site-specific data into a single 
place.  Within the mcollective init.pp manifest, I've identified four 
places for which I'd like to abstract data into hiera; they are:

$server= hiera('::mcollective::server'),
$client = hiera('::mcollective::client'),
$middleware = hiera('::mcollective::middleware'),
$middleware_hosts = hiera('::mcollective::middleware_hosts'),

I've created a fqdn specific hiera source (ourlocalhost.local.yaml) and 
added this:

classes: 
  - mcollective

# mcollective parameters
mcollective::middleware: true
mcollective::server: true
mcollective::client: true
mcollective::middleware_hosts:
  - ourlocalhost.local

Upon running puppet on this specific host, the puppet run completes and I 
marvel at the wonder of puppet and heiras' beautiful co-existence.

Now I'd like to simply add mcollective to any node in my network so I go to 
common.yaml and add the following:

classes:
  - mcollective

# mcollective parameters
mcollective::server: true
mcollective::middleware_hosts:
  - outlocalhost.local

However, upon running puppet on a fresh machine, I get the following error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find data item ::mcollective::client in any Hiera data file and 
no default supplied at 
/etc/puppet/environments/test/modules/mcollective/manifests/init.pp:5 on 
node mynode.local

If I add this line into common.yaml (mcollective::client: false) then I get 
the following failure:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find data item ::mcollective::middleware in any Hiera data file 
and no default supplied at 
/etc/puppet/environments/test/modules/mcollective/manifests/init.pp:6 on 
node mynode.local

If I then go back into common.yaml and add 'false' to the values I don't 
want, everything works:

classes: mcollective
mcollective::middleware: false
mcollective::server: true
mcollective::client: false
mcollective::middleware_hosts:
  - ourlocalhost.local


I've been searching for answers on the interwebs and haven't been able to 
find anything specific for this one so I figured I'd ask a few questions:

1.  Is this the expected functionality?  If so, am I to understand that I 
have to keep track of every hiera call (ex $server = 
hiera('::mcollective::server'), $client = hiera('::mcollective::client')), 
in my many modules and create defaults for each of these values in the 
various hiera source files that I create?  My understanding was that I 
could create these hiera calls in my classes and a al carte these values 
within my hiera source files.  Am I mistaken and if not, doesn't that 
create redundant data within my hiera source file tree?  Also, if future-me 
adds one additional hiera call to the init.pp, does that mean I have to 
track down every hiera data source and add a default value to each one?  

Which brings me to my next question:

2.  It seems that things could get messy very quickly if I am declaring 
parameters via hiera (let's take this mcollective example) and I have 
multiple hiera source files for which these values are declared.  As an 
example, let's say I have a custom fact which determines that a node is a 
'server' based on hostname. I then create a hiera data source called 
'server.yaml' and assign the mcollective parameters to that data source and 
all is well in the universe.  

But if I later I want to create a custom hostname data source for that 
server called 'nodename.yaml' and assign parameters from that source, I now 
have two places to check for declared values.  Additionally, if I go to the 
mcollective init.pp file, I simply see the source for that variable is 
being called from hiera but since I have two data sources, how will 
future-me know which one to check?  Further more, if I have a colleague 
that is just familiar enough with our infrastructure to check the init.pp 
and indeed he/she sees that the data is coming from hiera, he/she won't 
know where to look if we've defined the data in our 'server.yaml' our 
'node.yaml' and our 'common.yaml'.  Obviously this is a simplistic example 
but am I thinking about this wrong?  Perhaps I've missed/overlooked a major 
piece of the overall hiera design?  Or, I'm simply a jackass and I'm "using 
it wrong?" 

3.  If I want to add multiple 'classes' to say, common.yaml, is there a 
particular way in which I should is the below structure the preferred 
method and if so, does hiera parse these from top to bottom or am I likely 
to run into resource ordering problems in the future?:

classes:
  - one class
  - two class
  - three class

# class one parameters
stuff
blah

# class two parameters
stuff
blah

# class three parameters
st

[Puppet Users] hiera - default values must be specified?

[Mike Reed]

Hello all,

I ran into a problem with hiera and in particular, assigning or not 
assigning default values to variables within a data source.  I'm using the 
mcollective module (currently using version 1.1.6) and I've built a very 
simple hiera backend to start adding site-specific data into a single 
place.  Within the mcollective init.pp manifest, I've identified four 
places for which I'd like to abstract data into hiera; they are:

$server= hiera('::mcollective::server'),
$client = hiera('::mcollective::client'),
$middleware = hiera('::mcollective::middleware'),
$middleware_hosts = hiera('::mcollective::middleware_hosts'),

I've created a fqdn specific hiera source (ourlocalhost.local.yaml) and 
added this:

classes: mcollective
mcollective::middleware: true
mcollective::server: true
mcollective::client: true
mcollective::middleware_hosts:
  - ourlocalhost.local

Upon running puppet on this specific host, the puppet run completes and I 
marvel at the wonder of puppet and heiras' co-existence.

Now I'd like to simply add mcollective to any node in my network so I go to 
common.yaml and add the following:

classes:
  - mcollective

# mcollective parameters
mcollective::server: true
mcollective::middleware_hosts:
  - outlocalhost.local

However, upon running puppet on a fresh machine, I get the following error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find data item ::mcollective::client in any Hiera data file and 
no default supplied at 
/etc/puppet/environments/test/modules/mcollective/manifests/init.pp:5 on 
node mynode.local

If I add this line into common.yaml (mcollective::client: false) then I get 
the following failure:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Could not find data item ::mcollective::middleware in any Hiera data file 
and no default supplied at 
/etc/puppet/environments/test/modules/mcollective/manifests/init.pp:6 on 
node mynode.local

If I then go back into common.yaml and add 'false' to the values I don't 
want, everything works:

classes: mcollective
mcollective::middleware: false
mcollective::server: true
mcollective::client: false
mcollective::middleware_hosts:
  - ourlocalhost.local


I've been searching for answers on the interwebs and haven't been able to 
find anything specific for this one so I figured I'd ask a few questions:

1.  Is this the expected functionality?  If so, am I to understand that I 
have to keep track of every hiera call (ex $server = 
hiera('::mcollective::server'), $client = hiera('::mcollective::client')), 
in my many modules and create defaults for each of these values in the 
various hiera source files that I create?  My understanding was that I 
could create these hiera calls in my classes and a al carte these values 
within my hiera source files.  Am I mistaken and if not, doesn't that 
create redundant data within my hiera source file tree?  Also, if future-me 
adds one additional hiera call to the init.pp, does that mean I have to 
track down every hiera data source and add a default value to each one?  

Which brings me to my next question:

2.  It seems that things could get messy very quickly if I am declaring 
parameters via hiera (let's take this mcollective example) and I have 
multiple hiera source files for which these values are declared.  As an 
example, let's say I have a custom fact which determines that a node is a 
'server' based on hostname. I then create a hiera data source called 
'server.yaml' and assign the mcollective parameters to that data source and 
all is well in the universe.  

But if I later I want to create a custom hostname data source for that 
server called 'nodename.yaml' and assign parameters from that source, I now 
have two places to check for declared values.  Additionally, if I go to the 
mcollective init.pp file, I simply see the source for that variable is 
being called from hiera but since I have two data sources, how will 
future-me know which one to check?  Further more, if I have a colleague 
that is just familiar enough with our infrastructure to check the init.pp 
and indeed he/she sees that the data is coming from hiera, he/she won't 
know where to look if we've defined the data in our 'server.yaml' our 
'node.yaml' and our 'common.yaml'.  Obviously this is a simplistic example 
but am I thinking about this wrong?  Perhaps I've missed/overlooked a major 
piece of the overall hiera design?  Or, I'm simply a jackass and I'm "using 
it wrong?" 

Thank you in advance for your thoughts and my apologies for the long post.

Cheers,

Mike







-- 
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/18081c1c-01af-4763-ae74-9881e1ff8ba0%40googlegroups.co

Re: [Puppet Users] mcollective module - hiera integration

[Mike Reed]

Oops, I suppose if I would have read the module changelog, I could have 
avoided this entire post.  Thank you for the help and info...much 
appreciated.

Cheers,

m.  

On Thursday, September 11, 2014 12:16:18 PM UTC-7, Matthew Hyclak wrote:
>
> That option was removed in the latest version of the module[1]. You'll 
> have to roll back a version to do it that way, but the way forward appears 
> to be using an external option to configure the middleware for you. For 
> now, I just pinned version 1.1.6 until I can get time to implement the 
> middleware module as well.
>
> Matt
>
> [1] 
> https://github.com/puppetlabs/puppetlabs-mcollective/commit/9be4fed4e4474443a38bfefdd505356ac00b2333
>
> On Thu, Sep 11, 2014 at 2:48 PM, Mike Reed  > wrote:
>
>> Hello all,
>>
>> I have a quick question regarding the puppet-forge mcollective module and 
>> it's integration with hiera.  I'd like to abstract some values into hiera 
>> instead of using site.pp to define parameter values for the mcollective 
>> class.  I've got hiera and the mcollective module already working with the 
>> following two parameters (i've moved the $middleware hosts parameter for 
>> the sake of this post, from it's original location in init.pp):
>>
>> class mcollective (
>>   # which subcomponents to install here
>>   $server  = hiera('::mcollective::server'),
>>   $client   = hiera('::mcollective::client'),
>>   $middleware_hosts = hiera('::mcollective::middleware_hosts'),
>>
>> My hiera source looks like this:
>> ---
>> classes: mcollective
>> mcollective::middleware: true
>> mcollective::server: true
>> mcollective::middleware_hosts:
>>   - server-01.local
>>
>> So far everything is working fine but now I'd like to add the $middleware 
>> parameter and assign it to my hiera config (I've already added 'middleware' 
>> per the above definition).  The documentation states that I'd simply add 
>> the below 'middleware' parameter to my node definition:
>>
>> node 'broker1.example.com' {
>>   class { '::mcollective':
>> middleware => true,
>>
>>
>> The problem is that I can't find that value anywhere in the module to 
>> replace the default 'false' with my hiera directive.  I've been combing 
>> through the module and I can't seem to find it. My understanding is that I 
>> need to replace the 'middleware' parameter just like I did above with 
>> $server/$client.  
>>
>> Can anybody point me in the right direction on where I would change this 
>> value?  I'm still getting used to hiera and these module structures and, I 
>> do have to say that the mcollective module is probably the most complicated 
>> I've worked with so far.
>>
>> Thanks you in advance for your help.
>>
>> Cheers,
>>
>> Mike
>>
>>  -- 
>> 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/d7b52df3-aeaa-4cba-bc49-8743c0a89371%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/d7b52df3-aeaa-4cba-bc49-8743c0a89371%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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c3cf3c70-3f7b-4385-bb0b-19c72bce303b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] mcollective module - hiera integration

[Mike Reed]

Hello all,

I have a quick question regarding the puppet-forge mcollective module and 
it's integration with hiera.  I'd like to abstract some values into hiera 
instead of using site.pp to define parameter values for the mcollective 
class.  I've got hiera and the mcollective module already working with the 
following two parameters (i've moved the $middleware hosts parameter for 
the sake of this post, from it's original location in init.pp):

class mcollective (
  # which subcomponents to install here
  $server  = hiera('::mcollective::server'),
  $client   = hiera('::mcollective::client'),
  $middleware_hosts = hiera('::mcollective::middleware_hosts'),

My hiera source looks like this:
---
classes: mcollective
mcollective::middleware: true
mcollective::server: true
mcollective::middleware_hosts:
  - server-01.local

So far everything is working fine but now I'd like to add the $middleware 
parameter and assign it to my hiera config (I've already added 'middleware' 
per the above definition).  The documentation states that I'd simply add 
the below 'middleware' parameter to my node definition:

node 'broker1.example.com' {
  class { '::mcollective':
middleware => true,


The problem is that I can't find that value anywhere in the module to 
replace the default 'false' with my hiera directive.  I've been combing 
through the module and I can't seem to find it. My understanding is that I 
need to replace the 'middleware' parameter just like I did above with 
$server/$client.  

Can anybody point me in the right direction on where I would change this 
value?  I'm still getting used to hiera and these module structures and, I 
do have to say that the mcollective module is probably the most complicated 
I've worked with so far.

Thanks you in advance for your help.

Cheers,

Mike

-- 
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/d7b52df3-aeaa-4cba-bc49-8743c0a89371%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: client not seeing changes made on puppetmaster

[Mike Reed]

@Antoine you are exactly correct.  After creating an environment.conf file 
for my 'test' environment and setting 'environment_timeout = 0', it seems 
the cache is being cleared after each run and the appropriate changes are 
being reflected on my test clients.  I opted to create a .conf file for my 
specific environment and not change it globally as that seemed appropriate.

Thank you to the folks who took their own time to post suggestions and 
solutions to this one.

Cheers,

m.

On Friday, September 5, 2014 5:10:38 AM UTC-7, Antoine Cotten wrote:
>
> Hi Mike,
>
> It's very likely due to Directory Environments caching. By the default the 
> environment 
> timeout 
> <https://docs.puppetlabs.com/references/3.7.latest/configuration.html#environmenttimeout>
>  
> is 3m, which means you whole environment will cached during this time.
>
> You can enforce the value of this parameter to 0 if you do some testing 
> (make sure to restart your master), either per environment or globally in 
> your puppet.conf file.
>
> More information here: 
> https://docs.puppetlabs.com/puppet/latest/reference/environments_configuring.html#environmenttimeout
>
> Cheers,
>
> Toni
>
>
>
> On Thursday, September 4, 2014 9:28:10 PM UTC+2, Mike Reed wrote:
>>
>> Greetings,
>>
>> I have a class for which I would like to simply print a few parameters 
>> about a node, before actually running any additional modules on the client 
>> itself.  The problem I'm seeing is that after making changes to the class, 
>> I don't see them being propagated to the puppet client.  Occasionally if I 
>> restart puppet services on both client and master, the changes will get 
>> pulled down.  In other occasions, after a certain amount of time, the 
>> changes will just magically appear to get pulled down by the client.  Does 
>> anybody know why this may be occurring?  It's driving me mad.
>>
>> I have a vanilla puppet client running puppet 3.6.2 and a puppet master 
>> running version 3.6.2. and both have been recently built.
>>
>> *Site.pp:*
>>
>> # test node
>> node seanconnery-01 {
>>   include role
>> }
>>
>> class role {
>>   include profile::base
>> }
>>
>> class profile::base {
>>   include sys_ident
>> }
>>
>>
>> *sys_ident/init.pp*
>>
>> class sys_ident {
>>   notify { 'system hostname':
>> withpath => true,
>> name => "my fqdn is $fqdn",
>> }
>>
>>   notify {'network location':
>> withpath => true,
>> name => "my network is ${network}",
>>   }
>> }
>>
>> *Upon running the client, I get the expected output:*
>> seanconnery-01:~$ sudo puppet agent -tv
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Loading facts in /var/lib/puppet/lib/facter/network.rb
>> Info: Caching catalog for seanconnery-01.domain
>> Info: Applying configuration version '1409858463'
>> Notice: /Stage[main]/Sys_ident/Notify[network location]/message: my 
>> network is greenzone
>> Notice: /Stage[main]/Sys_ident/Notify[network location]/message: defined 
>> 'message' as 'my network is greenzone'
>> Notice: /Stage[main]/Sys_ident/Notify[system hostname]/message: my fqdn 
>> is seanconnery-01.domain
>> Notice: /Stage[main]/Sys_ident/Notify[system hostname]/message: defined 
>> 'message' as 'my fqdn is seanconnery-01.domain
>> Notice: Finished catalog run in 0.04 seconds
>>
>> *However, if I add another notify to the sys_ident/init.pp like so:*
>>
>> class sys_ident {
>>   notify { 'system hostname':
>> withpath => true,
>> name => "my fqdn is $fqdn",
>> }
>>
>>   notify {'network location':
>> withpath => true,
>> name => "my network is ${network}",
>>   }
>>
>>   notify {'swapfree':
>> withpath => true,
>> name => "my swap is ${swapfree}",
>>   }
>> }
>>
>> *I get the following on my client:*
>> seanconnery-01:~$ sudo puppet agent -tv
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Loading facts in /var/lib/puppet/lib/facter/network.rb
>> Info: Caching catalog for seanconnery-01.domain
>> Info: Applying configuration version '1409858679'
>> Notice: /Stage[main]/Sys_ident/Notify[network location]/message: my 
>> network is greenzone
>>

[Puppet Users] client not seeing changes made on puppetmaster

[Mike Reed]

Greetings,

I have a class for which I would like to simply print a few parameters 
about a node, before actually running any additional modules on the client 
itself.  The problem I'm seeing is that after making changes to the class, 
I don't see them being propagated to the puppet client.  Occasionally if I 
restart puppet services on both client and master, the changes will get 
pulled down.  In other occasions, after a certain amount of time, the 
changes will just magically appear to get pulled down by the client.  Does 
anybody know why this may be occurring?  It's driving me mad.

I have a vanilla puppet client running puppet 3.6.2 and a puppet master 
running version 3.6.2. and both have been recently built.

*Site.pp:*

# test node
node seanconnery-01 {
  include role
}

class role {
  include profile::base
}

class profile::base {
  include sys_ident
}


*sys_ident/init.pp*

class sys_ident {
  notify { 'system hostname':
withpath => true,
name => "my fqdn is $fqdn",
}

  notify {'network location':
withpath => true,
name => "my network is ${network}",
  }
}

*Upon running the client, I get the expected output:*
seanconnery-01:~$ sudo puppet agent -tv
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/network.rb
Info: Caching catalog for seanconnery-01.domain
Info: Applying configuration version '1409858463'
Notice: /Stage[main]/Sys_ident/Notify[network location]/message: my network 
is greenzone
Notice: /Stage[main]/Sys_ident/Notify[network location]/message: defined 
'message' as 'my network is greenzone'
Notice: /Stage[main]/Sys_ident/Notify[system hostname]/message: my fqdn is 
seanconnery-01.domain
Notice: /Stage[main]/Sys_ident/Notify[system hostname]/message: defined 
'message' as 'my fqdn is seanconnery-01.domain
Notice: Finished catalog run in 0.04 seconds

*However, if I add another notify to the sys_ident/init.pp like so:*

class sys_ident {
  notify { 'system hostname':
withpath => true,
name => "my fqdn is $fqdn",
}

  notify {'network location':
withpath => true,
name => "my network is ${network}",
  }

  notify {'swapfree':
withpath => true,
name => "my swap is ${swapfree}",
  }
}

*I get the following on my client:*
seanconnery-01:~$ sudo puppet agent -tv
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/network.rb
Info: Caching catalog for seanconnery-01.domain
Info: Applying configuration version '1409858679'
Notice: /Stage[main]/Sys_ident/Notify[network location]/message: my network 
is greenzone
Notice: /Stage[main]/Sys_ident/Notify[network location]/message: defined 
'message' as 'my network is greenzone'
Notice: /Stage[main]/Sys_ident/Notify[system hostname]/message: my fqdn is 
seanconnery-01.domain'
Notice: /Stage[main]/Sys_ident/Notify[system hostname]/message: defined 
'message' as 'my fqdn is seanconnery-01.domain'
Notice: Finished catalog run in 0.04 seconds

After a certain amount of undetermined time, the client will finally pickup 
the changes but there's no rhyme or reason to it.
Has anybody else ever seen this behavior?  I can't for the life of me 
figure it out.

As always, your help is much appreciated.

m.




-- 
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/0b060bc0-fb2e-4d72-80e9-063111dbf8ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: custom fact syntax

[Mike Reed]

Just in case anybody come across this post, I've used the following 
successfully:

require 'facter'
Facter.add('host_role') do
  setcode do
location = case Facter.value(:hostname)
  when /home/ then $&
  else 'unknown'
  end
  Q%[This is a #{location} server]
  end
end

I'm sure this can be done more elegantly but for now, it will work.

On Wednesday, September 3, 2014 2:40:13 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I'm looking to create a custom fact based on the result of a host name 
> prefix.  Some examples of host names are:
>
> home-server-01
> work-server-02
>
> I'd like the fact to assign a role to the server based on it's prefix and 
> I'm having a hard time getting this one to work:
>
> require 'facter'
> Facter.add('host_role') do
> setcode do
> hostname_array = Facter.value(:hostname).split('-')
> first_in_array = hostname_array.first
> first_in_array.each do |x|
> if x =~ /^(home|work)/
> role = '"#{x}" server'
> else
> role = 'other server'
> end
> role
> end
> end
>
> Would anybody have an pointers on why this may not be working.  I feel 
> stupid for asking this but my understanding of ruby is quite basic and 
> google has stopped taking my calls.
>
> Thank you in advance for the help.
>
> Cheers,
>
> Mike
>

-- 
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/30e17909-fd00-4267-a628-663d8da5e391%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] custom fact syntax

[Mike Reed]

Hello all,

I'm looking to create a custom fact based on the result of a host name 
prefix.  Some examples of host names are:

home-server-01
work-server-02

I'd like the fact to assign a role to the server based on it's prefix and 
I'm having a hard time getting this one to work:

require 'facter'
Facter.add('host_role') do
setcode do
hostname_array = Facter.value(:hostname).split('-')
first_in_array = hostname_array.first
first_in_array.each do |x|
if x =~ /^(home|work)/
role = '"#{x}" server'
else
role = 'other server'
end
role
end
end

Would anybody have an pointers on why this may not be working.  I feel 
stupid for asking this but my understanding of ruby is quite basic and 
google has stopped taking my calls.

Thank you in advance for the help.

Cheers,

Mike

-- 
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/b44ea4a2-caeb-45c8-8eee-ec6533485796%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] custom facter fact not available from client

[Mike Reed]

Hey Nan,

Thank you for pointing out the issue around "puts" and why the fact was 
never actually obtaining a value.  That makes sense and definitely fixes my 
problem.

Also, the irb is awesome and has significantly cut down my debugging time.  

Thank you for the quick response and for your help.  Much appreciated.

Cheers,

Mike

On Tuesday, September 2, 2014 1:04:17 PM UTC-7, Nan Liu wrote:
>
> On Tue, Sep 2, 2014 at 12:20 PM, Mike Reed  > wrote:
>
>> Hello all,
>>
>> I'm attempting to create a custom fact to identify the network to which a 
>> node belongs to. Below is the fact definition (I realize this fact isn't 
>> complete but wanted to test what I have so far):
>>
>> require 'facter'
>> Facter.add('network_geo') do
>>   setcode do
>> hostname   = Facter.value(:hostname)
>> hostname_array = hostname.split('-')
>>
>> # debug info
>> puts "My network is #{hostname_array}"
>>   end
>> end
>>
>> I then added the fact into a module named sys_ident and more 
>> specifically, into a directory like so: 
>> /modules/sys_ident/lib/facter/network_geo.rb
>>
>> For debugging purposes, I created a quick init.pp for the sys_ident 
>> module and added this:
>>
>> class sys_ident {
>>   notify{"My network identity is: ${network_geo}" :}
>>   notify{"My hostname identity is: ${hostname}" :}
>> }
>>
>> I then turned on pluginsync on both the puppetmaster and client within 
>> puppet.conf.
>>
>> After an initial run on my puppet client, I'm getting the following:
>>
>> seanconnery-02:/$ sudo puppet agent -tv
>> Info: Retrieving pluginfacts
>> Info: Retrieving plugin
>> Info: Loading facts in /var/lib/puppet/lib/facter/network_geo.rb
>> My network is ["seanconnery", "02"]
>> My network is ["seanconnery", "02"]
>> Info: Caching catalog for seanconnery-02.domain
>> Info: Applying configuration version '1409685071'
>> Notice: My network identity is:
>> Notice: /Stage[main]/Sys_ident/Notify[My network identity is: ]/message: 
>> defined 'message' as 'My network identity is: '
>> Notice: My hostname identity is: seanconnery-02
>> Notice: /Stage[main]/Sys_ident/Notify[My hostname identity is: 
>> seanconnery-02]/message: defined 'message' as 'My hostname identity is: 
>> seanconnery-02'
>> Notice: Finished catalog run in 0.04 seconds
>>
>> As you can see from the output, I'm not receiving the expected output 
>> from my "network_geo" notify parameter (also not sure why I'm getting the 
>> "My network" twice.  If I run facter from the puppet client, I get nothing 
>> in return:
>>
>> seanconnery-02:/$ facter -p network_geo
>>
>> For good measure, running the same command with the "hostname" fact 
>> produces this:
>>
>> seanconnery-02:/$ facter -p hostname
>> seanconnery-02
>>  
>> Based on the output from my client run, it does look like the fact is 
>> making it to the client but I can't seem to actually invoke it.  
>>
>> I feel that things are generally in the right place and after 
>> considerable troubleshooting, the only thing I can think of is a potential 
>> order-of-operations problem.  
>>
>> Does anybody have any suggestions as to why this may be occurring?
>>
>
> The puts command simply print a message and never returned a value for the 
> fact. You probably meant something along the lines of:
>
>  Facter.add('network_geo') do
>   setcode do
> hostname_array =  Facter.value(:hostname).split('-')
>
> # debug info
> puts "My network is #{hostname_array}"
> hostname_array.first
>   end
> end
>
> If you are developing facts, it's much easier to just drop into IRB and 
> get everything working there rather than doing round trip debugging between 
> puppet and facter:
>
> irb(main):001:0> require 'facter'
> => true
> irb(main):002:0> Facter.value("hostname")
> => "demo-1"
> irb(main):003:0> Facter.value("hostname").split('-')
> => ["demo", "1"]
>
> irb(main):006:0>  Facter.add('network_geo') do
> irb(main):007:1*   setcode do
> irb(main):008:2* hostname_array =  Facter.value(:hostname).split('-')
> irb(main):009:2>
> irb(main):010:2* # debug info
> irb(main):011:2* puts "My network is #{hostname_array}"
> irb(main):012:2> hostname_array.first
> irb(main):013:2>   end
> irb(main):014:1> end
> irb(main):015:0> Facter.value(:network_geo)
> My network is ["demo", "1"]
> => "demo"
>
> If you run your existing fact in irb, you'll see the output is nil instead:
>
> Facter.value(:network_geo)
> My network is ["demo", "1"]
> => nil
>
> HTH,
>
> Nan
>

-- 
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/35c55615-1dfd-4898-99cd-047a165abeed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] custom facter fact not available from client

[Mike Reed]

Hello all,

I'm attempting to create a custom fact to identify the network to which a 
node belongs to. Below is the fact definition (I realize this fact isn't 
complete but wanted to test what I have so far):

require 'facter'
Facter.add('network_geo') do
  setcode do
hostname   = Facter.value(:hostname)
hostname_array = hostname.split('-')

# debug info
puts "My network is #{hostname_array}"
  end
end

I then added the fact into a module named sys_ident and more specifically, 
into a directory like so: /modules/sys_ident/lib/facter/network_geo.rb

For debugging purposes, I created a quick init.pp for the sys_ident module 
and added this:

class sys_ident {
  notify{"My network identity is: ${network_geo}" :}
  notify{"My hostname identity is: ${hostname}" :}
}

I then turned on pluginsync on both the puppetmaster and client within 
puppet.conf.

After an initial run on my puppet client, I'm getting the following:

seanconnery-02:/$ sudo puppet agent -tv
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/network_geo.rb
My network is ["seanconnery", "02"]
My network is ["seanconnery", "02"]
Info: Caching catalog for seanconnery-02.domain
Info: Applying configuration version '1409685071'
Notice: My network identity is:
Notice: /Stage[main]/Sys_ident/Notify[My network identity is: ]/message: 
defined 'message' as 'My network identity is: '
Notice: My hostname identity is: seanconnery-02
Notice: /Stage[main]/Sys_ident/Notify[My hostname identity is: 
seanconnery-02]/message: defined 'message' as 'My hostname identity is: 
seanconnery-02'
Notice: Finished catalog run in 0.04 seconds

As you can see from the output, I'm not receiving the expected output from 
my "network_geo" notify parameter (also not sure why I'm getting the "My 
network" twice.  If I run facter from the puppet client, I get nothing in 
return:

seanconnery-02:/$ facter -p network_geo

For good measure, running the same command with the "hostname" fact 
produces this:

seanconnery-02:/$ facter -p hostname
seanconnery-02
 
Based on the output from my client run, it does look like the fact is 
making it to the client but I can't seem to actually invoke it.  

I feel that things are generally in the right place and after considerable 
troubleshooting, the only thing I can think of is a potential 
order-of-operations problem.  

Does anybody have any suggestions as to why this may be occurring?

Thank you in advance for your time and support and my apologies for the 
extra-long post.

Cheers,

Mike






-- 
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/024a85ed-fa17-4770-ba9c-2bcbff0c6b91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: creating custom facts - general usage

[Mike Reed]

On Tuesday, September 2, 2014 6:42:11 AM UTC-7, jcbollinger wrote:
>
>
>
> On Friday, August 29, 2014 5:05:01 PM UTC-5, Mike Reed wrote:
>>
>> Hello all,
>>
>> To start, I would like to thank you in advance for your responses.
>>
>> I'm attempting to create a custom fact that will determine the network 
>> location of a node, based on it's hostname.  Ideally this would be run on a 
>> node prior to the rest of the puppet modules because I will use the result 
>> as a top scope variable to assign certain values to nodes, based on their 
>> network location.  My node hostnames currently subscribe to this convention:
>>
>> network-hostname/role-number (ie. home-elastic-01/work-mysql-02)
>>
>
>
> I would like to suggest that you *not* do this via a fact.  More 
> generally, I consider it a principle of a good design to avoid creating any 
> fact that is strictly derivative of other facts.
>
> You can get a top scope variable with the same value in several other 
> ways, principal among them:
>
>1. Compute it directly at top scope in your site manifest
>2. Compute it in a class that manages no resources, 'include' that 
>class at top scope, and set the top-scope variable from the class variable
>
> As a subset of (1), you could consider creating and using a custom 
> function, which would be very clean as far as your manifests go.
>
> Note, however, that for *most* purposes you don't actually need a 
> top-scope variable; you could instead use a class variable directly.  
> Either way, you should be using a fully-qualified name everywhere you refer 
> to the variable in your manifests, so the choice of namespace is mostly a 
> personal preference in that context.  The only use I can think of where you 
> actually need a top-scope variable is if you want to interpolate it into 
> Hiera hierarchy definitions (which is indeed a perfectly reasonable thing 
> to do).
>
> Option 2 might look like this:
>
> modules/site/manifests/hostname_info.pp:
> 
> class site::hostname_info {
>   $hostname_parts = split($::hostname, '-')
>   $network = $hostname_parts[0]
>   $role = $hostname_parts[1]
>   $number = $hostname_parts[2]
> }
>
>
> manifests/site.pp (or any other manifest where you need the info):
> 
> # ...
> include 'site::hostname_info'
> $host_network = $site::hostname_info::network
> # ...
>
>
> John
>
>
Hello Felix and John,

First, thank you both for your responses and information.

In regards to John's post, you make a very interesting point and I didn't 
realize that I could achieve my objective without using a custom fact.  My 
goal is to extract all site-specific data to Heira in the near future so 
this custom-fact exercise does seem worth while but thank you for pointing 
out these alternate ways to achieve my goal.

Thanks again to both of you for the informative posts.

Cheers,

Mike

-- 
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/57d9f032-3adc-4291-be24-f0baa11e9a8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] creating custom facts - general usage

[Mike Reed]

Hello all,

To start, I would like to thank you in advance for your responses.

I'm attempting to create a custom fact that will determine the network 
location of a node, based on it's hostname.  Ideally this would be run on a 
node prior to the rest of the puppet modules because I will use the result 
as a top scope variable to assign certain values to nodes, based on their 
network location.  My node hostnames currently subscribe to this convention:

network-hostname/role-number (ie. home-elastic-01/work-mysql-02)

I've written a very simple fact to start with that looks like this (please 
excuse my code as I'm quite new to ruby):

# custom fact for determining network location of node
#
require 'facter'
Facter.add(:network_geo) do
  setcode do
hostname  = Facter.value(:hostname)
hostname_array = hostname.split('-')
hostname_array
  end
end

This fact obviously doesn't get me what I want yet, but I'd like to test 
this on a node to ensure basic parsing of the hostname and this is where my 
confusion comes in.  I've created a puppet module called sys_ident and 
added the above code into a file called network_geo.rb, located within the 
/sys_ident/files/ directory.  

It's my understanding that I have to add the /sys_ident/files/ path into 
either the RUBYLIB or FACTERLIB environment path and I've done that 
(although I don't understand how that fits into my master/agent setup and 
if I need to add this into the path in the first place).  However, my 
expectation was that after the above, I could simply run 'facter | grep 
network_geo' and I would see the hostname of my machine split up but that 
is not the case.  Instead, have to run 'facter -p network_geo' and I get 
the desired output.

So my question is, do I want to or should I expect to use a custom fact by 
simply running 'facter network_geo' or will I have to run 'facter -p 
' to invoke my fact.  Also, if I run puppet and this module 
does run, can I identify this fact as a normal top scope variable in my 
manifests ?

If anybody has a good link that explains this, I would be most appreciative 
as I'm a bit confused.

Once again, thank you for your time in advance as it's most appreciated.

Cheers,

Mike


-- 
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/fc786711-e4ab-405a-a00e-d43121275835%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet logging agent/master

[Mike Reed]

Hey Will and Ramin,

Thank you both for taking the time to explain your configurations.  

I suspect I'll roll with the central logging option via rsyslog/syslog and 
go from there.  Splunk sounds like a great tool to use for parsing as well 
as PuppetDB for more advanced visualization features.

Thanks again for the information as it's most appreicated.

Cheers,

Mike

On Tuesday, August 26, 2014 5:11:11 PM UTC-7, Wil Cooley wrote:
>
> kOn Tue, Aug 26, 2014 at 10:34 AM, Mike Reed  > wrote:
>
>> I suppose I have two questions:
>>
>> 1.  Is there a simple way to push messages to a file other than 
>> /var/log/syslog on an Ubuntu machine?
>>
>
> I think the rsyslog Ramin mentioned is a good way to filter.
>  
>
>> 2.  Is there a preferred way in the community by which people aggregate 
>> logs to make troubleshooting nodes issues easier to manage?
>>
>
> I use syslog forwarding to a central log collector and then use rsyslog 
> collector to separate the Puppet events to their own file. I feed the files 
> into Splunk.
>
> I also have a Puppet report-processor that logs via syslog with the data 
> in a key=value format, which is automatically extracted by Splunk but might 
> be useful for other log event management systems:
>
> https://forge.puppetlabs.com/wcooley/cimlog_report
>
> This only handles data from the agent (but it logged by the master); the 
> master can still have errors and data outside of the agents' reports that's 
> useful. For example, the catalog compile time is logged by the master and 
> some failures only show up on the master; analysing the Apache (or whatever 
> HTTP/Rack server you use) is also useful analysing what is being most 
> frequently requested.
>
> I have a Splunk app I've written (but never quite finished enough to push 
> to Splunk-base): 
>
> https://github.com/wcooley/splunk-puppet
>
> Much of this can be done with PuppetDB and Erik Dalen's demo Puppet 
> Explorer looks like it handles much of the visualization too.
>
> Wil
>  

-- 
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/268a7512-01a5-4b2d-8960-677ca1e27fa4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet logging agent/master

[Mike Reed]

Hello all,

I've recently been looking into various methods for configuring meaningful 
logging from my puppet 3.6 master/agent nodes.  I've typically gone the 
route of grep'ing through syslog on both master/agents and I'd like 
something a little more robust and user friendly for other who may not be 
hip on going through hundreds of lines of syslog information in addition to 
a simpler design.

I've recently been playing with an agent's puppet.conf and simply trying to 
set the logdir using this with no success at all (permissions have been 
changed to allow puppet to write to that directory):
[agent]
logdir=/var/log/puppet

I've also tested syslog facility configurations but after some time, it 
seemed like having to modify multiple configuration files to get puppet 
logging consistent, seems a bit bulky to me.

I suppose I have two questions:

1.  Is there a simple way to push messages to a file other than 
/var/log/syslog on an Ubuntu machine?
2.  Is there a preferred way in the community by which people aggregate 
logs to make troubleshooting nodes issues easier to manage?

Thank you all for your time in advance.

Cheers,

Mike

-- 
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/95bdc4eb-5650-4242-98c0-55fbd849c490%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Using a fact in "onlyif"

[Mike Reed]

Hey Peter,

Thank you for the info.  I'll read the attached link and get a better 
understanding of this one.  

As a note, the below if statement worked like a charm.

Thanks again for the help.

Cheers,

Mike

On Tuesday, April 22, 2014 11:23:44 AM UTC-7, Peter Bukowinski wrote:
>
> 'onlyif' is not a valid parameter for puppet 'file' type. Conditional 
> logic is handled by one of puppet's conditional statements (
> http://docs.puppetlabs.com/puppet/latest/reference/lang_conditional.html). 
>  In this case, wrapping your file resource in an 'if' statement will 
> suffice, but I encourage you to read the linked document to see what else 
> is possible.
>
> if $::operatingsystemrelease == "10.04" {
> file { "/var/lib/nfs/rpc_pipefs" :
> ensure   => "link" ,
> target=> "/run/rpc_pipefs" ,
> }
> }
>
> --
> Peter Bukowinski
>
> On Apr 22, 2014, at 2:09 PM, estonfer > 
> wrote:
>
> Since this shells out you could do something like this
>
>
> onlyif  => "[ '${::operatingsystemrelease}' = '10.04' ]",
>
>
> Thanks
> Eric
>
>
> On Apr 22, 2014, at 2:00 PM, Mike Reed > 
> wrote:
>
> Hello all,
>
> I've been stumped by this one and I was hoping for a little help.  I'd 
> like 
> the below snippet to run only if the operating system is a specific 
> version.  Because facter already has the "operatingsystemrelease" 
> variable, 
> I figured I'd use that but haven't had any luck getting it actually work.  
> Does anybody know how I would add the "onlyif" in the below snippet using 
> the "operatingsystemrelease" fact? 
>
> I also suspect this could be the wrong way to do this and any advice would 
> be greatly appreciated.
>
> file { "/var/lib/nfs/rpc_pipefs" :
>  ensure   => "link" ,
>  onlyif => "${operatingsystemrelease}" == "10.04" 
> ,
>  target=> "/run/rpc_pipefs" ,
>   }
>
> *note: this onlyif does not work...just added for clarity in terms of what 
> I'm trying to achieve
>
> Thanks in advance for the help.
>
> Cheers,
>
> Mike
>
> -- 
> 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/e27094d3-6774-4e21-bfe4-fe83895b84aa%40googlegroups.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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/1BD3237B-4FB1-4FFC-B0CF-1CA999A71D98%40gmail.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/d6779790-fb6a-4cb0-b329-08dd5a1195a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Using a fact in "onlyif"

[Mike Reed]

Hey Eric,

Thanks very much for the reply and info.  I added that in and it now looks 
like:

file { "/var/lib/nfs/rpc_pipefs" :
ensure  => "link" ,
onlyif  => "['${::operatingsystemrelease}' = 
'12.04']" ,
target  => "/run/rpc_pipefs" ,
}

Unfortunately, I'm getting this error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Invalid parameter onlyif at /etc/puppet/modules/autofs/manifests/init.pp:17

I'm trying to do some reading about this now but just wanted to get this 
back because I very much appreciate the help.

Cheers,

Mike

On Tuesday, April 22, 2014 11:09:34 AM UTC-7, Eric Stonfer wrote:
>
> Since this shells out you could do something like this 
>
>
> onlyif  => "[ '${::operatingsystemrelease}' = '10.04' ]", 
>
>
> Thanks 
> Eric 
>
>
> On Apr 22, 2014, at 2:00 PM, Mike Reed > 
> wrote: 
>
> > Hello all, 
> > 
> > I've been stumped by this one and I was hoping for a little help.  I'd 
> like 
> > the below snippet to run only if the operating system is a specific 
> > version.  Because facter already has the "operatingsystemrelease" 
> variable, 
> > I figured I'd use that but haven't had any luck getting it actually 
> work.   
> > Does anybody know how I would add the "onlyif" in the below snippet 
> using 
> > the "operatingsystemrelease" fact? 
> > 
> > I also suspect this could be the wrong way to do this and any advice 
> would 
> > be greatly appreciated. 
> > 
> > file { "/var/lib/nfs/rpc_pipefs" : 
> >   ensure   => "link" , 
> >   onlyif => "${operatingsystemrelease}" == 
> "10.04" 
> > , 
> >   target=> "/run/rpc_pipefs" , 
> >} 
> > 
> > *note: this onlyif does not work...just added for clarity in terms of 
> what 
> > I'm trying to achieve 
> > 
> > Thanks in advance for the help. 
> > 
> > Cheers, 
> > 
> > Mike 
> > 
> > -- 
> > 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/e27094d3-6774-4e21-bfe4-fe83895b84aa%40googlegroups.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/f65c7324-5fa5-4ef0-9da8-5e3a133b780c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Using a fact in "onlyif"

[Mike Reed]

Hello all,

I've been stumped by this one and I was hoping for a little help.  I'd like 
the below snippet to run only if the operating system is a specific 
version.  Because facter already has the "operatingsystemrelease" variable, 
I figured I'd use that but haven't had any luck getting it actually work.  
Does anybody know how I would add the "onlyif" in the below snippet using 
the "operatingsystemrelease" fact? 

I also suspect this could be the wrong way to do this and any advice would 
be greatly appreciated.

file { "/var/lib/nfs/rpc_pipefs" :
   ensure   => "link" ,
   onlyif => "${operatingsystemrelease}" == "10.04" 
,
   target=> "/run/rpc_pipefs" ,
}

*note: this onlyif does not work...just added for clarity in terms of what 
I'm trying to achieve

Thanks in advance for the help.

Cheers,

Mike

-- 
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/e27094d3-6774-4e21-bfe4-fe83895b84aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet & augeas - where to put augeas definition?

[Mike Reed]

Hey Pete,

Thanks for the info.  I think adding a class and "futureproofing" for 
things like dependencies is probably the way to go, in this specific 
scenario.  

Many thanks for the link and for the great information below.  I owe you a 
beer.

Cheers,

Mike


On Thursday, January 23, 2014 12:29:19 AM UTC-8, Peter Meier wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA1 
>
> Hi 
>
> > Per the snippet above, I'm simply trying to add in an extra entry 
> > into my /etc/apt/sources.list but I'm not sure where I would 
> > actually put the above piece of code.  I currently have it sitting 
> > in my init.pp file for the corresponding class but I'm not sure if 
> > that's really where it belongs. 
> > 
> > Is the init.pp file the right place for this and if not, where 
> > would I put it? 
> > 
> > My apologies if this is a stupid question as I'm having a hard 
> > time wrapping my head around this one. 
>
> The answer totally depends on how you would like to structure your 
> modules. 
>
> Given that you are managing apt-stuff I would assume that you have 
> something like an apt-module and I would place it within there. 
>
> You could place it there in the init.pp in the apt-class and on all 
> your debian systems, you would do an "include apt". However you might 
> not want this repository to be present on all nodes, actually only on 
> the ones that need the client-repo. 
> So then a class called apt::repos::client (in the apt-modules in 
> manifests/repos/client.pp ) might be the better place to put it and 
> include this class on all nodes that require this repository. 
>
> This has even a different advantage: Maybe the main purpose for this 
> repository is have the packages available to install certain 
> applications - that you are also managing by puppet. So you could 
> include this repo-class only in the classes that manage the packages 
> for these applications (specify a dependency!) and you have not 
> anymore to think about this apt-dependency if you apply a certain 
> application-class to a node. 
>
> But this might already be a little bit off-the-topic. Anyway 
> http://www.slideshare.net/PuppetLabs/roles-talkis
>  really a good 
> practice to structure your puppet code. 
>
> ~pete 
> -BEGIN PGP SIGNATURE- 
> Version: GnuPG v1 
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ 
>
> iEYEARECAAYFAlLg0tkACgkQbwltcAfKi3+YzACfSSsiJpa0nr9/XvpNjRNtIS1L 
> RXwAn3UPFCCJVC4F3twiozCGNqI4PAoI 
> =I0Xj 
> -END PGP SIGNATURE-   
>

-- 
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/7eaf0b77-9fd6-41c0-a5dd-d42119edb21b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppet & augeas - where to put augeas definition?

[Mike Reed]

Hello all,

I'm looking to use a simple augeas definition per the below info:

 augeas { "sources_config":
context => "/files/etc/apt/sources.list" ,
changes => [
"set deb http://repo/ client main" ,
],
}

Per the snippet above, I'm simply trying to add in an extra entry into my 
/etc/apt/sources.list but I'm not sure where I would actually put the above 
piece of code.  I currently have it sitting in my init.pp file for the 
corresponding class but I'm not sure if that's really where it belongs.

Is the init.pp file the right place for this and if not, where would I put 
it?

My apologies if this is a stupid question as I'm having a hard time 
wrapping my head around this one.

Thanks in advance for all the help.

Cheers,

Mike

-- 
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/6a05ba6a-c3fd-4de1-abca-31593b6b233f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] if/or regex entry

[Mike Reed]

Thank you very much Peter.

I also found that putting the regex entry in single quotes - as in my above 
examples - does not give me the expected results.  As per your example, the 
regex entries are properly parsed when entries start and end with a forward 
slash.

I hope this helps somebody else down the line.

Cheers and thanks again.

Mike

On Wednesday, September 18, 2013 9:43:22 AM UTC-7, pmbuko wrote:
>
> On Sep 18, 2013, at 12:33 PM, Mike Reed > 
> wrote: 
>
> > Hello all, 
> > 
> > I've been fighting a pesky regex issue and I was hoping somebody might 
> have a solution handy.  I'm trying to evaluate the hostname variable based 
> on a few regex entries and apply some configurations accordingly. 
> > 
> > Here's what I've got: 
> > 
> > if ($hostname == '/^([a-z]*[-]\d{2,})*$/') or ($hostname == 
> '/^([a-zA-Z0-9])*$/') { 
> > 
> > another variant: 
> > 
> > if ($hostname == '/^([a-z]*[-]\d{2,})*$/') || ($hostname == 
> '/^([a-zA-Z0-9])*$/') { 
> > 
> > I expect the second option to work as it seems - according to my reading 
> - to be more "ruby friendly". 
> > 
> > Has anybody used this syntax successfully in the past?  Additionally, I 
> suspect I could be bastardizing this as I'm not familiar with ruby. 
> > 
> > Thanks in advance for the help. 
> > 
> > Cheers, 
> > 
> > Mike 
>
> Since you're doing regex matching you need to use the '=~' operator 
> instead of '==', like so: 
>
> if ( $::hostname =~ /^foo/ ) or ( $::hostname =~ /^bar/ ) { 
>
> -- 
> Peter Bukowinski

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] if/or regex entry

[Mike Reed]

Hello all,

I've been fighting a pesky regex issue and I was hoping somebody might have 
a solution handy.  I'm trying to evaluate the hostname variable based on a 
few regex entries and apply some configurations accordingly.

Here's what I've got:

if ($hostname == '/^([a-z]*[-]\d{2,})*$/') or ($hostname == 
'/^([a-zA-Z0-9])*$/') {

another variant: 

if ($hostname == '/^([a-z]*[-]\d{2,})*$/') || ($hostname == 
'/^([a-zA-Z0-9])*$/') {

I expect the second option to work as it seems - according to my reading - 
to be more "ruby friendly".

Has anybody used this syntax successfully in the past?  Additionally, I 
suspect I could be bastardizing this as I'm not familiar with ruby.

Thanks in advance for the help.

Cheers,

Mike

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] node based regex entries

[Mike Reed]

Hey Iain,

Thanks for the reply and the suggestion.  That one got me close but didn't 
give me exactly what I needed.  Consequently, this did:   node 
/^(sbx-.*-\d\d$)/

Thanks again for the suggestion and the help.

Cheers,

Mike

On Tuesday, March 12, 2013 6:54:50 PM UTC-7, nseagoon wrote:
>
> rubular.com suggests that the regex should be ^sbx-.*-\d\d$
>
> On 13 March 2013 12:16, Mike Reed >wrote:
>
>> Hello all,
>>
>> I've been trying to configure node-based regex entries and puppet seems 
>> to be giving me a hard time with this one.
>>
>> Our system naming convention is this: 
>>
>> sbx--.  
>>
>> For instance, we have: sbx-circle-01 and sbx-square-01 both on the same 
>> network.
>>
>> I'm using this entry:  node /^sbx-[^\.*]\-\d\d$/ and I suspect I'm 
>> missing something as I don't get an error when running sbx-circle-01 
>> against it, but the manifests never get pulled down.
>>
>> Does anybody have any suggestions on how I might fix this up?
>>
>> If I wasn't already bald, I would have pulled my hair out trying to 
>> figure this one.
>>
>> As always, thanks in advance for the help and support.
>>
>> Cheers,
>>
>> Mike
>>
>> -- 
>> 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 post to this group, send email to puppet...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] node based regex entries

[Mike Reed]

Hello all,

I've been trying to configure node-based regex entries and puppet seems to 
be giving me a hard time with this one.

Our system naming convention is this: 

sbx--.  

For instance, we have: sbx-circle-01 and sbx-square-01 both on the same 
network.

I'm using this entry:  node /^sbx-[^\.*]\-\d\d$/ and I suspect I'm missing 
something as I don't get an error when running sbx-circle-01 against it, 
but the manifests never get pulled down.

Does anybody have any suggestions on how I might fix this up?

If I wasn't already bald, I would have pulled my hair out trying to figure 
this one.

As always, thanks in advance for the help and support.

Cheers,

Mike

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Organization of puppet classes

[Mike Reed]

Thanks very much Joe.  I'll take a look and go from there.

Much appreciated.

Cheers,

Mike

On Monday, March 11, 2013 5:21:01 PM UTC-7, joe wrote:
>
> You want roles and profiles:
> http://www.craigdunn.org/2012/05/239/
>
> On Monday, March 11, 2013 6:02:15 PM UTC-6, Mike Reed wrote:
>>
>> Hello All,
>>
>> I've been looking for a simple way to clean up my nodes.pp file and I was 
>> hoping to get some suggestions from you folks.  At the moment, I keep all 
>> my class definitions within nodes.pp.  It currently looks something like 
>> this:
>>
>> ### regex based workstation nodes 
>>   node /^sbx-[^\s]*$/ {
>>   include gen-lucid-stages
>>   class { sbx-lucid-base-security : stage => security }
>>   class { sbx-lucid-workstation-base  : stage => packages }
>>   class { sbx-lucid-base-upgrade  : stage => upgrade }
>>   class { sbx-lucid-base-dist-upgrade : stage => dist-upgrade 
>> }
>>   class { sbx-lucid-base-filesystem   : stage => filesystem }
>>   class { sbx-lucid-base-graphics : stage => graphics }
>>   class { sbx-lucid-weta-config   : stage => configs }
>>  }
>>
>> ### Lucid Groupings 
>> class sbx-lucid-base-security {
>> include sbx-lucid-common-puppet
>> include sbx-lucid-common-auth
>> include sbx-lucid-common-powerbroker
>> }
>> class sbx-lucid-workstation-base {
>> include sbx-lucid-workstation-default
>> }
>> class sbx-lucid-base-upgrade {
>> include sbx-lucid-common-upgrade
>> }
>> class sbx-lucid-base-dist-upgrade {
>> include sbx-lucid-common-dist-upgrade
>> }
>> class sbx-lucid-base-filesystem {
>> include sbx-lucid-common-autofs
>> include sbx-lucid-common-softlinks
>> }
>> class sbx-lucid-base-graphics {
>> include sbx-lucid-common-kubuntu-desktop
>> include sbx-lucid-common-weta-kde
>> include sbx-lucid-common-nvidia-driver-29553
>> }
>>
>> This however seems a bit cluttered and I was hoping to move these classes 
>> out of nodes.pp and into somewhere a bit more tidy.  It's probably my 
>> rudimentary understanding of puppet but are there any suggestions into how 
>> I might achieve this?
>>
>> Thanks in advance for the help on this one.
>>
>> Cheers,
>>
>> Mike
>>
>

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Organization of puppet classes

[Mike Reed]

Hello All,

I've been looking for a simple way to clean up my nodes.pp file and I was 
hoping to get some suggestions from you folks.  At the moment, I keep all 
my class definitions within nodes.pp.  It currently looks something like 
this:

### regex based workstation nodes 
  node /^sbx-[^\s]*$/ {
  include gen-lucid-stages
  class { sbx-lucid-base-security : stage => security }
  class { sbx-lucid-workstation-base  : stage => packages }
  class { sbx-lucid-base-upgrade  : stage => upgrade }
  class { sbx-lucid-base-dist-upgrade : stage => dist-upgrade }
  class { sbx-lucid-base-filesystem   : stage => filesystem }
  class { sbx-lucid-base-graphics : stage => graphics }
  class { sbx-lucid-weta-config   : stage => configs }
 }

### Lucid Groupings 
class sbx-lucid-base-security {
include sbx-lucid-common-puppet
include sbx-lucid-common-auth
include sbx-lucid-common-powerbroker
}
class sbx-lucid-workstation-base {
include sbx-lucid-workstation-default
}
class sbx-lucid-base-upgrade {
include sbx-lucid-common-upgrade
}
class sbx-lucid-base-dist-upgrade {
include sbx-lucid-common-dist-upgrade
}
class sbx-lucid-base-filesystem {
include sbx-lucid-common-autofs
include sbx-lucid-common-softlinks
}
class sbx-lucid-base-graphics {
include sbx-lucid-common-kubuntu-desktop
include sbx-lucid-common-weta-kde
include sbx-lucid-common-nvidia-driver-29553
}

This however seems a bit cluttered and I was hoping to move these classes 
out of nodes.pp and into somewhere a bit more tidy.  It's probably my 
rudimentary understanding of puppet but are there any suggestions into how 
I might achieve this?

Thanks in advance for the help on this one.

Cheers,

Mike

-- 
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Running "make" via puppet manifest

[Mike Reed]

Thank you all for the responses.  I think the solution of scripting the 
install and calling the script via puppet is an interesting thought. 
 Thanks as well for the suggested reading.

Cheers,

Mike

On Wednesday, August 1, 2012 12:56:11 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I've been banging my head against the wall trying to get this "make" to 
> run and I was hoping to get some opinions as to why this might not be 
> working.  The module in question looks like this:
>
>  class install-lei_chelsio_driver {
> # This will place the chelsio tarball locally in /usr/src.  File 
> is pulled from puppet.
> file { "/usr/src/ChelsioUwire-1.0.2.26.tar.gz" :
> source  => 
> "puppet:///install-lei_chelsio_driver/ChelsioUwire-1.0.2.26.tar.gz" ,
> ensure  => present ,
> }
>
> # Untar the tarball 
> exec { "/bin/tar -xvf /usr/src/ChelsioUwire-1.0.2.26.tar.gz" :
> cwd => "/usr/src/" ,
> creates => "/usr/src/ChelsioUwire-1.0.2.26" ,
> }
>
> # This will run the make which will line up everything to install 
> the drivers from source.
> exec { "/usr/src/ChelsioUwire-1.0.2.26 make 
> KDIR=/usr/src/linux-headers-2.6.32-41" :
> path => "/usr/src/ChelsioUwire-1.0.2.26" ,
> }
> }
>
> This is the error I get upon running a machine against the manifest:
>
> err: 
> /Stage[main]/Install-lei_chelsio_driver/Exec[/usr/src/ChelsioUwire-1.0.2.26 
> make KDIR=/usr/src/linux-headers-2.6.32-41]/returns: change from notrun to 
> 0 failed: /usr/src/ChelsioUwire-1.0.2.26 make 
> KDIR=/usr/src/linux-headers-2.6.32-41 returned 1 instead of one of [0] at 
> /etc/puppet/modules/install-lei_chelsio_driver/manifests/init.pp:20   
>
> I added the "path" parameter for good measure and still no dice.  
>
> Any suggestions as to why this one won't properly fire?
>
> As always, the help and support are much appreciated.
>
> Cheers,
>
> Mike
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/AihRUzCvjQ0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Running "make" via puppet manifest

[Mike Reed]

Hello all,

I've been banging my head against the wall trying to get this "make" to run 
and I was hoping to get some opinions as to why this might not be working. 
 The module in question looks like this:

 class install-lei_chelsio_driver {
# This will place the chelsio tarball locally in /usr/src.  File is 
pulled from puppet.
file { "/usr/src/ChelsioUwire-1.0.2.26.tar.gz" :
source  => 
"puppet:///install-lei_chelsio_driver/ChelsioUwire-1.0.2.26.tar.gz" ,
ensure  => present ,
}

# Untar the tarball 
exec { "/bin/tar -xvf /usr/src/ChelsioUwire-1.0.2.26.tar.gz" :
cwd => "/usr/src/" ,
creates => "/usr/src/ChelsioUwire-1.0.2.26" ,
}

# This will run the make which will line up everything to install 
the drivers from source.
exec { "/usr/src/ChelsioUwire-1.0.2.26 make 
KDIR=/usr/src/linux-headers-2.6.32-41" :
path => "/usr/src/ChelsioUwire-1.0.2.26" ,
}
}

This is the error I get upon running a machine against the manifest:

err: 
/Stage[main]/Install-lei_chelsio_driver/Exec[/usr/src/ChelsioUwire-1.0.2.26 
make KDIR=/usr/src/linux-headers-2.6.32-41]/returns: change from notrun to 
0 failed: /usr/src/ChelsioUwire-1.0.2.26 make 
KDIR=/usr/src/linux-headers-2.6.32-41 returned 1 instead of one of [0] at 
/etc/puppet/modules/install-lei_chelsio_driver/manifests/init.pp:20   

I added the "path" parameter for good measure and still no dice.  

Any suggestions as to why this one won't properly fire?

As always, the help and support are much appreciated.

Cheers,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/x2zv2n4k4b8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Multiple execs within a class

[Mike Reed]

Hey Guys,

Thank you Peter and John for your continued input into this one.   I 
absolutely agree with both of you about building our own packages and as 
I've been working with puppet and trying to configure these systems, it's 
become apparent that our own internal repository would be beneficial for a 
number of reasons.

With that said, I'm quite new to the 'nix world and I suspect building out 
packages/repository would take a little time and probably a few days of 
googl'in.  So for the very immediate future, I'd like to get this working 
so I can get our initial puppet build going.  packages/repository are 
definitely on my list tho.

I'd like to quickly mention that the impetus behind this is that I'd like 
to run this against machines that we've built up without puppet and if 
possible, I'd like to refrain from things like the below manifest being run 
on a machine which already has boost installed, albeit manually without 
puppet.

I changed the class to the following:

class boost_install {
# This will place the gzip locally in /tmp.  File is pulled from 
puppet.
file { "/tmp/boost_1_41_0.tar.bz2" :
source  => "puppet:///boost_install/boost_1_41_0.tar.bz2" ,
ensure  => present ,
}

# This will extract the boost gzip to the /tmp directory.
exec { "untar_boost" :
command => "tar -xjvf /tmp/boost_1_41_0.tar.bz2" ,
cwd => "/tmp/" ,
creates => "/tmp/boost_1_41_0" ,
path=> ["/bin" , "/usr/sbin"] ,
require => File["/tmp/boost_1_41_0.tar.bz2"] ,
}

# This will run the boost bootstrapper
exec { "/tmp/boost_1_41_0/bootstrap.sh" :
subscribe => Exec["untar_boost"] ,
}
}

>From the above code, I expect a few things to happen:
1. The exec "untar_boost" should only fire if "/tmp/boost_1_41_0.tar.bz2" 
is present
2. The exec "/tmp/boost_1_41_0/bootstrap.sh" should only fire if the untar 
boost occurs, which I believe is dependent upon the file being in that 
location.  (I'm thinking this will work as a temporary dependency as I'm 
not sure how to make a dependency for the initial file being pulled down.  
In other words, I expect the file to be pulled down on every run which I 
guess is something I'll have to fix later).  I'm thinking if I change from 
/tmp to something like /usr/src/puppet_pkgs then the files won't be deleted 
upon reboot and I can use them as a temporary placeholder until I figure 
out a more elegant solution to this hack that I've put together.

I'm sorry for writing the novel above and I very much appreciate your help 
and support on this one. 

Cheers,

Mike
 

On Thursday, July 5, 2012 9:53:26 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I'm looking to run multiple commands via exec within a single class like 
> so:
>
> class boost_install {
> # This will place the gzip locally in /tmp.  File is pulled from 
> puppet.
> file { "/tmp/boost_1_41_0.tar.bz2" :
> source  => "puppet:///boost_install/boost_1_41_0.tar.bz2" ,
> ensure  => present ,
> }
>
> # This will extract the boost gzip to the /tmp directory.
> # This will untar only if the /tmp/boost_1_41_0 directory does not 
> exist.
> exec { "tar -xjvf /tmp/boost_1_41_0.tar.bz2" :
> cwd => "/tmp/" ,
> creates => "/tmp/boost_1_41_0" ,
> path=> ["/bin" , "/usr/sbin"] ,
> }
>
> # This will run the boost bootstrapper. bjam should be run after 
> this.
> # This will only run if the ls command returns a 1.
> # The unless will have to be redone because we have no way of 
> upgrading easily and this is sloppy.
> exec{ "/tmp/boost_1_41_0/bootstrap.sh" :
> unless  => 'ls /usr/local/include/boost' ,
> path=> ["/bin/" , "/sbin/" , "/usr/bin/" , 
> "/usr/sbin/"] ,
> }
>
> # This will run the boost bjam modifier and should run only after 
> the bootstrap.sh has been run
> # This will only run if the ls command returns a 1.
> # This unless  will have to be redone because we have no way of 
> upgrading easily and this is sloppy.
> exec { "/tmp/boost_1_41_0/bjam cxxflags=-fPIC install" :
> unless  => 'ls /usr/local/include/boost' ,
>   

[Puppet Users] Multiple execs within a class

[Mike Reed]

Hello all,

I'm looking to run multiple commands via exec within a single class like so:

class boost_install {
# This will place the gzip locally in /tmp.  File is pulled from 
puppet.
file { "/tmp/boost_1_41_0.tar.bz2" :
source  => "puppet:///boost_install/boost_1_41_0.tar.bz2" ,
ensure  => present ,
}

# This will extract the boost gzip to the /tmp directory.
# This will untar only if the /tmp/boost_1_41_0 directory does not 
exist.
exec { "tar -xjvf /tmp/boost_1_41_0.tar.bz2" :
cwd => "/tmp/" ,
creates => "/tmp/boost_1_41_0" ,
path=> ["/bin" , "/usr/sbin"] ,
}

# This will run the boost bootstrapper. bjam should be run after 
this.
# This will only run if the ls command returns a 1.
# The unless will have to be redone because we have no way of 
upgrading easily and this is sloppy.
exec{ "/tmp/boost_1_41_0/bootstrap.sh" :
unless  => 'ls /usr/local/include/boost' ,
path=> ["/bin/" , "/sbin/" , "/usr/bin/" , 
"/usr/sbin/"] ,
}

# This will run the boost bjam modifier and should run only after 
the bootstrap.sh has been run
# This will only run if the ls command returns a 1.
# This unless  will have to be redone because we have no way of 
upgrading easily and this is sloppy.
exec { "/tmp/boost_1_41_0/bjam cxxflags=-fPIC install" :
unless  => 'ls /usr/local/include/boost' ,
path=> ["/bin/" , "/sbin/" , "/usr/bin/" , 
"/usr/sbin/"]  ,
}
}

However, after running the above class, I get the following:

err: 
/Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bootstrap.sh]/returns: 
change from notrun to 0 failed: /tmp/boost_1_41_0/bootstrap.sh returned 1 
instead of one of [0] at 
/etc/puppet/modules/boost_install/manifests/init.pp:18
err: /Stage[main]/Boost_install/Exec[/tmp/boost_1_41_0/bjam cxxflags=-fPIC 
install]/returns: change from notrun to 0 failed: /tmp/boost_1_41_0/bjam 
cxxflags=-fPIC install returned 1 instead of one of [0] at 
/etc/puppet/modules/boost_install/manifests/init.pp:21
notice: Finished catalog run in 1.31 seconds

I was under the impression that I should be getting the "install returned 
1" output but it's usually silent and the command doesn't run.  I'm 
assuming that neither the bootstrap or bjam commands should run as the 
/usr/local/include/boost directories exist on the machine and I'm expecting 
the "ls" to return a 0; which it does on the machine because those 
directories exist.

I'm obviously missing something here and I'm looking for some direction.

I do suspect that this can be done in a more elegant fashion especially 
since the bjam command is dependent upon the bootstrap.sh script running 
but I was hoping to at least get this working.

Thanks in advance for the thoughts.

Cheers,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/EU_MKz-02H0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Double quotes within an exec statement

[Mike Reed]

Hey Guys, 

Thanks for the input.   Your comments were most helpful and I definitely 
get it now.

I realize that the way I'm going about doing this one probably isn't the 
most desirable and as soon as I have my important manifests working in a 
basic state, I'll come back to each one and fix them up.

Thanks again for the help.

Cheers,

Mike

On Thursday, July 5, 2012 1:23:47 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I've been trying to run this exec statement (which to my peril was 
> initially thought to be something simple):
>
> exec { "/opt/pbis/bin/config UserDomainPrefix "" " :  }
>
> After the command is run I'm getting the following error:
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Syntax error at '' '; expected '}' at 
> /etc/puppet/modules/powerbroker_install/manifests/init.pp:20 on node 
> sbxwk-blackhole.sbx.leiproductions.com
>
> I need to run the command with the double quotes as the value of 
> UserDomainPrefix but I'm having a hard time getting this one to run.  I 
> figured if I changed to the command below, puppet wouldn't interpret the 
> double quotes and things would work but I was quite wrong. 
>
> exec { " '/opt/pbis/bin/config UserDomainPrefix "" '  " :  }
>
> Does anybody have any suggestions as to how one might run an exec with 
> double quotes?
>
> As always, thanks for the help in advance.
>
> Cheers,
>
> Mike 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/TxrnTcgquB4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Double quotes within an exec statement

[Mike Reed]

Hello all,

I've been trying to run this exec statement (which to my peril was 
initially thought to be something simple):

exec { "/opt/pbis/bin/config UserDomainPrefix "" " :  }

After the command is run I'm getting the following error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Syntax error at '' '; expected '}' at 
/etc/puppet/modules/powerbroker_install/manifests/init.pp:20 on node 
sbxwk-blackhole.sbx.leiproductions.com

I need to run the command with the double quotes as the value of 
UserDomainPrefix but I'm having a hard time getting this one to run.  I 
figured if I changed to the command below, puppet wouldn't interpret the 
double quotes and things would work but I was quite wrong. 

exec { " '/opt/pbis/bin/config UserDomainPrefix "" '  " :  }

Does anybody have any suggestions as to how one might run an exec with 
double quotes?

As always, thanks for the help in advance.

Cheers,

Mike 


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/nDswUwx_4tsJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Nvidia driver install - condition for install

[Mike Reed]

Hey All,

I got moved onto another project and I hadn't been able to get back to this 
one until today.  I first wanted to thank you all for the information and 
suggestions.  I'll take a look and see what I can do and I'll be sure to 
let everybody know what the outcome is.  

I like Nan's suggestion about a custom fact but I'm not quite there in my 
knowledge yet so I suspect I'll use some mix of a relation and a simple 
"if" statement.

Cheers,

Mike

On Friday, June 29, 2012 11:29:57 AM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I'd like to use puppet to install an Nvidia driver on a local workstation. 
>  I've written the following manifest for this puprpose:
>
> class nvidia_driver {
> # This will place the nvidia installer locally in /tmp.  File is 
> pulled from puppet.
> file { "/tmp/NVIDIA-Linux-x86_64-295.53.run" :
> source  => 
> "puppet:///modules/nvidia_driver/NVIDIA-Linux-x86_64-295.53.run" ,
> ensure  => present ,
> }
>
> # This will run the nvidia installer locally on the machine.  
> exec { "/tmp/NVIDIA-Linux-x86_64-295.53.run -s -X --opengl-headers 
> --no-distro-scripts --force-tls-compat32=new" :  }
>  
> }
>
> Upon the initial run of the manifest on the target machine, everything 
> works great (although I do believe there is some room for improvement of 
> the code above; particularly on the exec portion) and the driver then gets 
> installed.  The issue occurs on subsequent puppet runs on the same machine 
> and I'm getting the following error during my second puppet run from the 
> client:
>
> err: /Stage[main]/Nvidia_driver/Exec[/tmp/NVIDIA-Linux-x86_64-295.53.run 
> -s -X --opengl-headers --no-distro-scripts 
> --force-tls-compat32=new]/returns: change from notrun to 0 failed: 
> /tmp/NVIDIA-Linux-x86_64-295.53.run -s -X --opengl-headers 
> --no-distro-scripts --force-tls-compat32=new returned 1 instead of one of 
> [0] at /etc/puppet/modules/nvidia_driver/manifests/init.pp:12
>
> It appears to me that the above error is occurring because the 
> nvidia_driver class is running on each subsequent run and since the driver 
> is already installed, I'm getting an exit status of 1 instead of 0, which 
> to my knowledge would be expected.  
>
> So, what I'd like to do is put some sort of condition that will look to 
> see if the driver is installed and if it is, the class "nvidia_driver" 
> won't run.  I'm having a hard time figuring this one out and I was hoping 
> to get a few opinions on how this might be accomplished.  
>
> Would this potentially be a job for a shell script that does the checking? 
>  Maybe just adding the shell script into the "nvidia_driver" manifest?  
>
> Thanks in advance for everybody's assistance and the help is very much 
> appreciated.
>
> Cheers,
>
> Mike
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/Qf-UpAH1cLcJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Nvidia driver install - condition for install

[Mike Reed]

Hello all,

I'd like to use puppet to install an Nvidia driver on a local workstation. 
 I've written the following manifest for this puprpose:

class nvidia_driver {
# This will place the nvidia installer locally in /tmp.  File is 
pulled from puppet.
file { "/tmp/NVIDIA-Linux-x86_64-295.53.run" :
source  => 
"puppet:///modules/nvidia_driver/NVIDIA-Linux-x86_64-295.53.run" ,
ensure  => present ,
}

# This will run the nvidia installer locally on the machine.  
exec { "/tmp/NVIDIA-Linux-x86_64-295.53.run -s -X --opengl-headers 
--no-distro-scripts --force-tls-compat32=new" :  }
 
}

Upon the initial run of the manifest on the target machine, everything 
works great (although I do believe there is some room for improvement of 
the code above; particularly on the exec portion) and the driver then gets 
installed.  The issue occurs on subsequent puppet runs on the same machine 
and I'm getting the following error during my second puppet run from the 
client:

err: /Stage[main]/Nvidia_driver/Exec[/tmp/NVIDIA-Linux-x86_64-295.53.run -s 
-X --opengl-headers --no-distro-scripts --force-tls-compat32=new]/returns: 
change from notrun to 0 failed: /tmp/NVIDIA-Linux-x86_64-295.53.run -s -X 
--opengl-headers --no-distro-scripts --force-tls-compat32=new returned 1 
instead of one of [0] at 
/etc/puppet/modules/nvidia_driver/manifests/init.pp:12

It appears to me that the above error is occurring because the 
nvidia_driver class is running on each subsequent run and since the driver 
is already installed, I'm getting an exit status of 1 instead of 0, which 
to my knowledge would be expected.  

So, what I'd like to do is put some sort of condition that will look to see 
if the driver is installed and if it is, the class "nvidia_driver" won't 
run.  I'm having a hard time figuring this one out and I was hoping to get 
a few opinions on how this might be accomplished.  

Would this potentially be a job for a shell script that does the checking? 
 Maybe just adding the shell script into the "nvidia_driver" manifest?  

Thanks in advance for everybody's assistance and the help is very much 
appreciated.

Cheers,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/R9ngLgt78tMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Distribution upgrade and subsequent reboot of machine

[Mike Reed]

Hey Pete,

I haven't had a chance to venture into mcollective yet but that's a great 
thought and I'll put that on my list of things to "investigate".  I'm only 
running puppet against one machine and it's a box I don't care about so 
I'll give this a run and see how it goes.  I wanted to thank you for the 
suggestion and help.

Cheers,

Mike

On Tuesday, June 26, 2012 6:37:52 PM UTC-7, Pete wrote:
>
> Hi Mike, 
>
> Just as a side not I would be rather hesitant to set this up with puppet. 
> This may be a job for some other tool like mcollective but I have not 
> ventured into the land yet. 
>
> This may work but I haven't done any testing so please test this on a 
> non production server before rolling it out. 
>
> I would try a notify in your exec { 
> "purge_linux-image-2.6.32-38-server" : resource and take the subscribe 
> out of the reboot. 
>
> Something like this. 
>
> exec { "purge_linux-image-2.6.32-38-server" : 
> command => "/usr/bin/apt-get -y purge 
> linux-image-2.6.32-38-server" , 
> require => Exec['purge_linux-headers-2.6.32-38'] , 
> notify   => Exec["reboot_after_dist_upgrade"] 
> } 
> #This is done so the system starts using the new headers/image 
> exec { "reboot_after_dist_upgrade" : 
> command => "/sbin/reboot" , 
> refreshonly => true , 
> } 
>
>
> On 27 June 2012 11:12, Mike Reed wrote: 
> > Hello all, 
> > 
> > In building out an initial workstation configuration (Ubuntu 10.04 
> lucid) 
> > via Puppet, I have the need to do two things in order.  The first is to 
> do a 
> > dist-upgrade on the workstation and reboot, followed by an install of a 
> > Nvida driver.  Upon doing a dist-upgrade, I have to reboot the machine 
> in 
> > order for the workstation to start using the new linux-headers because 
> if I 
> > install the Nvidia drivers without doing a reboot after a dist-upgrade, 
> the 
> > drivers will compile against the old headers and my gui no longer works 
> and 
> > X won't start because of a modprobe issue. 
> > 
> > With that said, I've written the dist-upgrade manifest as so: 
> > 
> > class dist_upgrade { 
> > exec { "dist_upgrade" : 
> > command => "/usr/bin/apt-get -y dist-upgrade" , 
> > } 
> > 
> > exec { "purge_linux-headers-2.6.32-38" : 
> > command => "/usr/bin/apt-get -y purge 
> > linux-headers-2.6.32-38" , 
> > require => Exec['dist_upgrade'] , 
> > } 
> > 
> > exec { "purge_linux-image-2.6.32-38-server" : 
> > command => "/usr/bin/apt-get -y purge 
> > linux-image-2.6.32-38-server" , 
> > require => Exec['purge_linux-headers-2.6.32-38'] , 
> > } 
> > 
> > #This is done so the system starts using the new headers/image 
> > exec { "reboot_after_dist_upgrade" : 
> > command => "/sbin/reboot" , 
> > subscribe => Exec["purge_linux-image-2.6.32-38-server"] 
> , 
> > refreshonly => true , 
> > } 
> > } 
> > 
> > This seems to be doing the job but I feel it's a bit of a hack and I was 
> > wondering if anybody had an opinion as to if this can be done in a 
> cleaner 
> > fashion.  I'm still very new to Puppet so please excuse my novice 
> example. 
> > 
> > Thanks in advance for the help and support. 
> > 
> > Cheers, 
> > 
> > Mike 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msg/puppet-users/-/R5BQkgRvyt4J. 
> > To post to this group, send email to puppet-users@googlegroups.com. 
> > To unsubscribe from this group, send email to 
> > puppet-users+unsubscr...@googlegroups.com. 
> > For more options, visit this group at 
> > http://groups.google.com/group/puppet-users?hl=en. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/sc_uIsXu_wEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Distribution upgrade and subsequent reboot of machine

[Mike Reed]

Hey John,

Thanks for the reply.  I'll look up the 'onlyif' and 'unless' usage and see 
which might best suit my needs.  Thank you for pointing me in the right 
direction.

Cheers,

Mike

On Wednesday, June 27, 2012 8:02:16 AM UTC-7, jcbollinger wrote:
>
>
>
> On Tuesday, June 26, 2012 8:12:05 PM UTC-5, Mike Reed wrote:
>>
>> exec { "purge_linux-image-2.6.32-38-server" :
>> command => "/usr/bin/apt-get -y purge 
>> linux-image-2.6.32-38-server" ,
>> require => Exec['purge_linux-headers-2.6.32-38'] ,
>> }
>>
>> #This is done so the system starts using the new headers/image
>> exec { "reboot_after_dist_upgrade" :
>> command => "/sbin/reboot" ,
>> subscribe => Exec["purge_linux-image-2.6.32-38-server"] ,
>> refreshonly => true ,
>> }
>>
>
> That combination is wrong if you do not in fact intend for Puppet to 
> reboot the machine on every run.  The problem is that Exec["
> purge_linux-image-2.6.32-38-server"] runs its command every time, and any 
> time an Exec runs its command is considered a change (thus triggering 
> subscribers to refresh).  You can avoid that by setting an appropriate 
> command in the 'onlyif' or 'unless' parameter of that Exec; these plus 
> 'creates' are how an Exec determines whether it is already in sync.
>
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/rTrzbZna438J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Distribution upgrade and subsequent reboot of machine

[Mike Reed]

As an update, after running this a few times after this initial post, I'm 
seeing the machine reboot after new classes have been added which is not 
desired.  I might have to rethink the reboot approach.

Thanks again,

Mike

On Tuesday, June 26, 2012 6:12:05 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> In building out an initial workstation configuration (Ubuntu 10.04 lucid) 
> via Puppet, I have the need to do two things in order.  The first is to do 
> a dist-upgrade on the workstation and reboot, followed by an install of a 
> Nvida driver.  Upon doing a dist-upgrade, I have to reboot the machine in 
> order for the workstation to start using the new linux-headers because if I 
> install the Nvidia drivers without doing a reboot after a dist-upgrade, the 
> drivers will compile against the old headers and my gui no longer works and 
> X won't start because of a modprobe issue.
>
> With that said, I've written the dist-upgrade manifest as so:
>
> class dist_upgrade {
> exec { "dist_upgrade" :
> command => "/usr/bin/apt-get -y dist-upgrade" ,
> }
>
> exec { "purge_linux-headers-2.6.32-38" :
> command => "/usr/bin/apt-get -y purge 
> linux-headers-2.6.32-38" ,
> require => Exec['dist_upgrade'] ,
> }
>
> exec { "purge_linux-image-2.6.32-38-server" :
> command => "/usr/bin/apt-get -y purge 
> linux-image-2.6.32-38-server" ,
> require => Exec['purge_linux-headers-2.6.32-38'] ,
> }
>
> #This is done so the system starts using the new headers/image
> exec { "reboot_after_dist_upgrade" :
> command => "/sbin/reboot" ,
> subscribe => Exec["purge_linux-image-2.6.32-38-server"] ,
> refreshonly => true ,
> }
> }
>
> This seems to be doing the job but I feel it's a bit of a hack and I was 
> wondering if anybody had an opinion as to if this can be done in a cleaner 
> fashion.  I'm still very new to Puppet so please excuse my novice example.
>
> Thanks in advance for the help and support.
>
> Cheers,
>
> Mike
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/57Oa8W-NhqgJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Distribution upgrade and subsequent reboot of machine

[Mike Reed]

Hello all,

In building out an initial workstation configuration (Ubuntu 10.04 lucid) 
via Puppet, I have the need to do two things in order.  The first is to do 
a dist-upgrade on the workstation and reboot, followed by an install of a 
Nvida driver.  Upon doing a dist-upgrade, I have to reboot the machine in 
order for the workstation to start using the new linux-headers because if I 
install the Nvidia drivers without doing a reboot after a dist-upgrade, the 
drivers will compile against the old headers and my gui no longer works and 
X won't start because of a modprobe issue.

With that said, I've written the dist-upgrade manifest as so:

class dist_upgrade {
exec { "dist_upgrade" :
command => "/usr/bin/apt-get -y dist-upgrade" ,
}

exec { "purge_linux-headers-2.6.32-38" :
command => "/usr/bin/apt-get -y purge 
linux-headers-2.6.32-38" ,
require => Exec['dist_upgrade'] ,
}

exec { "purge_linux-image-2.6.32-38-server" :
command => "/usr/bin/apt-get -y purge 
linux-image-2.6.32-38-server" ,
require => Exec['purge_linux-headers-2.6.32-38'] ,
}

#This is done so the system starts using the new headers/image
exec { "reboot_after_dist_upgrade" :
command => "/sbin/reboot" ,
subscribe => Exec["purge_linux-image-2.6.32-38-server"] ,
refreshonly => true ,
}
}

This seems to be doing the job but I feel it's a bit of a hack and I was 
wondering if anybody had an opinion as to if this can be done in a cleaner 
fashion.  I'm still very new to Puppet so please excuse my novice example.

Thanks in advance for the help and support.

Cheers,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/R5BQkgRvyt4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet Configuration - Running --configprint generates long list of values

[Mike Reed]

Hey Nick,

Thank you for the reply.  I'll take a look at the defaults.rb file and see 
what I can make of it.  The explanation regarding the "core group" settings 
is most helpful and makes perfect sense.  

Again, thanks for the informative links and the info.

Cheers,

Mike

On Wednesday, June 20, 2012 1:20:08 PM UTC-7, Nick Fagerlund wrote:
>
>
>
> On Wednesday, June 20, 2012 12:38:58 PM UTC-7, Mike Reed wrote:
>>
>>  My question is where do these parameters and values come from?  I've 
>> taken a look at my puppet.conf file...
>
>
> Defaults! Even if you only SET a few settings in puppet.conf, all of the 
> POSSIBLE settings still have values. These default values are set in a file 
> called defaults.rb, which is part of Puppet's code. See it here: 
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/defaults.rbOr you 
> can see the config reference at 
> http://docs.puppetlabs.com/references/latest/configuration.html --- that 
> explains most of the default values. 
>
> You'll notice that many settings are set *in terms of* other settings, so 
> that you end up only really having to set a small core group of settings. 
>
> What is that small core group? Well... that's kind of tricky to tease out, 
> actually. The historical context is that we've tended to make every global 
> constant in Puppet's code into a configurable setting, and the result is 
> that we have over 200 of them. We know that's a problem; a lot of the work 
> we're doing these days can be summarized as "reduce configuration, make 
> things more knowable." But once you add a configurable knob, someone might 
> start using it, and removing it becomes a lot harder than not having put it 
> in would have been. 
>
> But the list of the most important settings here (
> http://docs.puppetlabs.com/guides/configuring.html#puppets-settings) is a 
> good place to start. You won't need to know much more than that for a 
> while. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/s2yDN87HwEoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet Configuration - Running --configprint generates long list of values

[Mike Reed]

Thank you for the reply Craig.  That makes sense and points me in the right 
direction.

Thanks again,

Mike

On Wednesday, June 20, 2012 1:06:09 PM UTC-7, Craig White wrote:
>
>
> On Jun 20, 2012, at 12:38 PM, Mike Reed wrote: 
>
> > Hello all, 
> > 
> > I fairly new to puppet and google groups so I'll apologize in advance 
> for not conforming to "normal" posting methods. 
> > 
> > I've recently installed puppetmaster on a fresh copy of Ubuntu 10.04LTS 
> and after running: sudo puppet --configprint all, I get a long list of 
> parameters and values echoed back to my shell.  My question is where do 
> these parameters and values come from?  I've taken a look at my puppet.conf 
> file (which I believe is located in the proper place of: 
> /etc/puppet/puppet.conf) and it looks like this: 
> > 
> > [main] 
> > logdir=/var/log/puppet 
> > vardir=/var/lib/puppet 
> > ssldir=/var/lib/puppet/ssl 
> > rundir=/var/run/puppet 
> > factpath=$vardir/lib/facter 
> > templatedir=$confdir/templates 
> > 
> > [master] 
> > # These are needed when the puppetmaster is run by passenger 
> > # and can safely be removed if webrick is used. 
> > ssl_client_header = SSL_CLIENT_S_DN 
> > ssl_client_verify_header = SSL_CLIENT_VERIFY 
> > 
> > Clearly these values of the ''--configprint -all" command are coming 
> from somewhere else and I can't seem to find the answer.   
> > 
> > I've read that puppet will read values from a users home directory if 
> the puppet service is not running as root but I'm not sure that's something 
> I should be concerned with at the moment. 
>  
> --configprint will supplement anything not specifically configured in 
> puppet.conf with its own defaults. Thus you can 'override' any of the 
> defaults by specifically declaring them in the appropriate section of 
> puppet.conf 
>
> Craig

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/64QGtHcvLRQJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Puppet Configuration - Running --configprint generates long list of values

[Mike Reed]

Hello all,

I fairly new to puppet and google groups so I'll apologize in advance for 
not conforming to "normal" posting methods.

I've recently installed puppetmaster on a fresh copy of Ubuntu 10.04LTS and 
after running: sudo puppet --configprint all, I get a long list of 
parameters and values echoed back to my shell.  My question is where do 
these parameters and values come from?  I've taken a look at my puppet.conf 
file (which I believe is located in the proper place of: 
/etc/puppet/puppet.conf) and it looks like this:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
templatedir=$confdir/templates

[master]
# These are needed when the puppetmaster is run by passenger
# and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN 
ssl_client_verify_header = SSL_CLIENT_VERIFY

Clearly these values of the ''--configprint -all" command are coming from 
somewhere else and I can't seem to find the answer.  

I've read that puppet will read values from a users home directory if the 
puppet service is not running as root but I'm not sure that's something I 
should be concerned with at the moment.

My thanks to everybody's help in advance.

Cheers,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/H2P51DT0WfMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.