Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Jim Perry]

Thanks.

While I see that Ansible is a nice tool, the clientless access requiring a
login has a fatal flaw when compared to puppet.

More than once we have had a PAM, SSHD or similar setup get corrupted over
dozens, if not all, systems. We were able to fix in Puppet and get the
corrections pushed out. With Ansible we would have needed to hard shut then
down and come up in single user mode.

In fact this very post is related to ensuring we can fix issues with PAM
related to our third party AD with tool.  We had a typo in the setup that
locked all access, even console, out because we broke PAM.

On Sep 16, 2016 03:06, "Thomas Müller"  wrote:



Am Donnerstag, 15. September 2016 14:53:57 UTC+2 schrieb HPUX_PUPPET:
>
> ...
>
> This post was mainly about seeing if Puppet / Factor had been tweaked over
> the years to pull lists of installed RPMs given Red Hat Satellite 6 using
> Puppet as part of their software management and server build solution.
>
>  unfortunatly besides integration of Puppet in foreman GUI it's not very
sophisticated in sense of additonal features to manage RHEL systems. I
first hoped they will release supported puppet modules to make
configuration of basic stuff easy but this did not happen.

now they bought ansible I don't think they will make investments in better
support. IMHO Puppet 4 is still not supported on the satellite 6 server.

- Thomas

-- 
You received this message because you are subscribed to a topic in the
Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/puppet-users/xJh1au94dqE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/puppet-users/d48d5590-cda0-4052-a727-295ec3e891dc%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/CAO0AM%3DoFWPK%3DO7OKiO-vGy6MHcOj3t6ZOvGOtTwb7jc9H0GvEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Thomas Müller]

Am Donnerstag, 15. September 2016 14:53:57 UTC+2 schrieb HPUX_PUPPET:
>
> ...
>
> This post was mainly about seeing if Puppet / Factor had been tweaked over 
> the years to pull lists of installed RPMs given Red Hat Satellite 6 using 
> Puppet as part of their software management and server build solution. 
>
>  unfortunatly besides integration of Puppet in foreman GUI it's not very 
sophisticated in sense of additonal features to manage RHEL systems. I 
first hoped they will release supported puppet modules to make 
configuration of basic stuff easy but this did not happen. 

now they bought ansible I don't think they will make investments in better 
support. IMHO Puppet 4 is still not supported on the satellite 6 server. 

- 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/d48d5590-cda0-4052-a727-295ec3e891dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Rob Nelson]

I don't think you'll see that added as a core fact because it would still
have a relatively narrow appeal. Due to the partnership between RH/Puppet,
there may be a Satellite mod that includes such a custom fact. If you do
something like that yourself, I would keep an eye on
https://tickets.puppetlabs.com/browse/FACT-348 and the RFC for a
facter.conf file that includes TTL/caching, since that would be a pretty
heavyweight fact to generate.

Glad you found a solution. That sounds like a hairy problem in general!


Rob Nelson
rnels...@gmail.com

On Thu, Sep 15, 2016 at 8:53 AM, HPUX_PUPPET  wrote:

> I only wish it was that simple and thus the problem i had been facing.
>
> The 3rd party package requires hands-on steps to get installed, but the
> package itself isn't the issue. It is that it puts 2-5 lines at the head of
> the PAM module conf files (system-auth, password-auth, common-auth, ...).
> If the lines are pushed by a default configuration and the software it not
> installed or connected to AD, then you can't get in, even with root. You
> have to boot to single-user mode to correct it. When pushing out PAM setups
> to servers, we cannot assume the 3rd party software has been installed at
> that point.
>
> But thanks to your great encouragement, I wrote some down and dirty custom
> facts that check if it is installed and if so, the version as well. I put
> the fact in the module directory and it deployed immediately.  Not the
> experience I had with the 0.25 puppet client at all.
>
> Now I have the easy part of checking to ensure the package is installed to
> add the lines to variables I am using in the PAM template files.
>
> This post was mainly about seeing if Puppet / Factor had been tweaked over
> the years to pull lists of installed RPMs given Red Hat Satellite 6 using
> Puppet as part of their software management and server build solution.
>
> On Wednesday, September 14, 2016 at 1:31:37 PM UTC-4, Rob Nelson wrote:
>>
>> Are there cases where a node might not have the package, ever? Or do you
>> just want to make sure it's done in the right order? If you did this:
>>
>>   package{'some-pam-package':
>> ensure => present,
>>   }
>>
>> ...and the package was already installed, nothing would happen. However
>> you could then leverage that, as in the previous example, in ordering to
>> make sure the file shows up afterward.
>>
>> You could put this in a profile that is only applied to certain
>> roles/nodes, or some other conditional (i.e. a param `$manage_pam` to a
>> profile where, when true, the example code is hit), to restrict which nodes
>> receive that in their catalog. This lets the 'package' type do its job
>> rather than writing more complicated code and conditional, and protects you
>> if somehow that package is uninstalled - puppet will enforce the desired
>> state and re-install the package and configuration.
>>
>> Does that make sense?
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Wed, Sep 14, 2016 at 9:32 AM, HPUX_PUPPET  wrote:
>>
>>> Thanks Rob!
>>>
>>> I am sort of "starting fresh" so I have a lot of latitude here. The way
>>> it was done before was shoddy and required a lot of files, so I am trying
>>> to reduce them.
>>>
>>> I will go back to investigating a custom fact.  I have used them in the
>>> past, but the problem was more related to needing to manually go to each
>>> host to restart puppet so it would recognize that a fact had been added.
>>>
>>> Unfortunately installing PAM is less the issue as having customized
>>> lines that need to be added to the top of the files for servers using the
>>> 3rd party AD authentication for boxes where it is installed. As they had
>>> mandatory require lines, if the files are not there, we are locked out.
>>> Currently we a file param to create the needed files in temp on all boxes
>>> and then if the software was installed, we would switch files. Trying to
>>> keep it less kludgy so I was seeing if Puppet could use an RPM list from
>>> the host to check. A custom fact seems the best way to go here.
>>>
>>>
>>> On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:

 I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you
 are stair stepping or starting fresh), they mostly "just work". Throw them
 in a module and poof, agents get them on the next run, and they're
 processed before the catalog compilation of that run so they take effect
 immediately. Learning Just Enough Ruby(TM) also should not make you too
 shy. A long time ago, I wrote a sample custom fact that parses a hostname
 with a regex and grabs a portion of the string (
 https://github.com/puppetinabox/controlrepo/blob/production
 /dist/profile/lib/facter/puppet_role.rb) - if you are comfortable with
 regex, you can probably pick up the minimal ruby required to understand the
 rest of it. It wouldn't be too difficult to add a system() call to rpm and
 check the return code.

 All t

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[HPUX_PUPPET]

I only wish it was that simple and thus the problem i had been facing.

The 3rd party package requires hands-on steps to get installed, but the 
package itself isn't the issue. It is that it puts 2-5 lines at the head of 
the PAM module conf files (system-auth, password-auth, common-auth, ...). 
 If the lines are pushed by a default configuration and the software it not 
installed or connected to AD, then you can't get in, even with root. You 
have to boot to single-user mode to correct it. When pushing out PAM setups 
to servers, we cannot assume the 3rd party software has been installed at 
that point. 

But thanks to your great encouragement, I wrote some down and dirty custom 
facts that check if it is installed and if so, the version as well. I put 
the fact in the module directory and it deployed immediately.  Not the 
experience I had with the 0.25 puppet client at all.  

Now I have the easy part of checking to ensure the package is installed to 
add the lines to variables I am using in the PAM template files. 

This post was mainly about seeing if Puppet / Factor had been tweaked over 
the years to pull lists of installed RPMs given Red Hat Satellite 6 using 
Puppet as part of their software management and server build solution. 

On Wednesday, September 14, 2016 at 1:31:37 PM UTC-4, Rob Nelson wrote:
>
> Are there cases where a node might not have the package, ever? Or do you 
> just want to make sure it's done in the right order? If you did this:
>
>   package{'some-pam-package':
> ensure => present,
>   }
>
> ...and the package was already installed, nothing would happen. However 
> you could then leverage that, as in the previous example, in ordering to 
> make sure the file shows up afterward.
>
> You could put this in a profile that is only applied to certain 
> roles/nodes, or some other conditional (i.e. a param `$manage_pam` to a 
> profile where, when true, the example code is hit), to restrict which nodes 
> receive that in their catalog. This lets the 'package' type do its job 
> rather than writing more complicated code and conditional, and protects you 
> if somehow that package is uninstalled - puppet will enforce the desired 
> state and re-install the package and configuration.
>
> Does that make sense?
>
>
> Rob Nelson
> rnel...@gmail.com 
>
> On Wed, Sep 14, 2016 at 9:32 AM, HPUX_PUPPET  > wrote:
>
>> Thanks Rob!
>>
>> I am sort of "starting fresh" so I have a lot of latitude here. The way 
>> it was done before was shoddy and required a lot of files, so I am trying 
>> to reduce them. 
>>
>> I will go back to investigating a custom fact.  I have used them in the 
>> past, but the problem was more related to needing to manually go to each 
>> host to restart puppet so it would recognize that a fact had been added. 
>>
>> Unfortunately installing PAM is less the issue as having customized lines 
>> that need to be added to the top of the files for servers using the 3rd 
>> party AD authentication for boxes where it is installed. As they had 
>> mandatory require lines, if the files are not there, we are locked out. 
>> Currently we a file param to create the needed files in temp on all boxes 
>> and then if the software was installed, we would switch files. Trying to 
>> keep it less kludgy so I was seeing if Puppet could use an RPM list from 
>> the host to check. A custom fact seems the best way to go here. 
>>
>>
>> On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:
>>>
>>> I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you 
>>> are stair stepping or starting fresh), they mostly "just work". Throw them 
>>> in a module and poof, agents get them on the next run, and they're 
>>> processed before the catalog compilation of that run so they take effect 
>>> immediately. Learning Just Enough Ruby(TM) also should not make you too 
>>> shy. A long time ago, I wrote a sample custom fact that parses a hostname 
>>> with a regex and grabs a portion of the string (
>>> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/lib/facter/puppet_role.rb)
>>>  
>>> - if you are comfortable with regex, you can probably pick up the minimal 
>>> ruby required to understand the rest of it. It wouldn't be too difficult to 
>>> add a system() call to rpm and check the return code.
>>>
>>> All that said, perhaps instead of using a fact, you could use ordering 
>>> within your puppet manifest, to implement the PAM module first, THEN update 
>>> the config via template afterward. This could be as simple as this:
>>>
>>>   package{'pam-additional-module':
>>> ensure => present,
>>>   } ->
>>>   file{'pam-additional-module-config':
>>> ensure => present,
>>> path => /etc/pam.d/additional.conf,
>>> contents => template('profile/pam/additional.conf.erb'),
>>>   }
>>>
>>> This would install the package 'pam-additional-module', then install a 
>>> configuration file for it based on an ERB template. Just an example you can 
>>> ada

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Rob Nelson]

Are there cases where a node might not have the package, ever? Or do you
just want to make sure it's done in the right order? If you did this:

  package{'some-pam-package':
ensure => present,
  }

...and the package was already installed, nothing would happen. However you
could then leverage that, as in the previous example, in ordering to make
sure the file shows up afterward.

You could put this in a profile that is only applied to certain
roles/nodes, or some other conditional (i.e. a param `$manage_pam` to a
profile where, when true, the example code is hit), to restrict which nodes
receive that in their catalog. This lets the 'package' type do its job
rather than writing more complicated code and conditional, and protects you
if somehow that package is uninstalled - puppet will enforce the desired
state and re-install the package and configuration.

Does that make sense?


Rob Nelson
rnels...@gmail.com

On Wed, Sep 14, 2016 at 9:32 AM, HPUX_PUPPET  wrote:

> Thanks Rob!
>
> I am sort of "starting fresh" so I have a lot of latitude here. The way it
> was done before was shoddy and required a lot of files, so I am trying to
> reduce them.
>
> I will go back to investigating a custom fact.  I have used them in the
> past, but the problem was more related to needing to manually go to each
> host to restart puppet so it would recognize that a fact had been added.
>
> Unfortunately installing PAM is less the issue as having customized lines
> that need to be added to the top of the files for servers using the 3rd
> party AD authentication for boxes where it is installed. As they had
> mandatory require lines, if the files are not there, we are locked out.
> Currently we a file param to create the needed files in temp on all boxes
> and then if the software was installed, we would switch files. Trying to
> keep it less kludgy so I was seeing if Puppet could use an RPM list from
> the host to check. A custom fact seems the best way to go here.
>
>
> On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:
>>
>> I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you
>> are stair stepping or starting fresh), they mostly "just work". Throw them
>> in a module and poof, agents get them on the next run, and they're
>> processed before the catalog compilation of that run so they take effect
>> immediately. Learning Just Enough Ruby(TM) also should not make you too
>> shy. A long time ago, I wrote a sample custom fact that parses a hostname
>> with a regex and grabs a portion of the string (
>> https://github.com/puppetinabox/controlrepo/blob/production
>> /dist/profile/lib/facter/puppet_role.rb) - if you are comfortable with
>> regex, you can probably pick up the minimal ruby required to understand the
>> rest of it. It wouldn't be too difficult to add a system() call to rpm and
>> check the return code.
>>
>> All that said, perhaps instead of using a fact, you could use ordering
>> within your puppet manifest, to implement the PAM module first, THEN update
>> the config via template afterward. This could be as simple as this:
>>
>>   package{'pam-additional-module':
>> ensure => present,
>>   } ->
>>   file{'pam-additional-module-config':
>> ensure => present,
>> path => /etc/pam.d/additional.conf,
>> contents => template('profile/pam/additional.conf.erb'),
>>   }
>>
>> This would install the package 'pam-additional-module', then install a
>> configuration file for it based on an ERB template. Just an example you can
>> adapt. I hope that helps!
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Tue, Sep 13, 2016 at 2:10 PM, HPUX_PUPPET  wrote:
>>
>>> I am moving from Puppet 0.25 to Puppet 4.  In doing so I am re-writing a
>>> lot of the modules to work better than what I inherited.
>>>
>>> So my current issue I am trying to figure out is how to update PAM
>>> variables based on what external 3rd party authentication package we have
>>> installed on that server. The old method that had been employed was to use
>>> an exec to push a file with the correct settings.  I am trying to do it via
>>> a template.
>>>
>>> The problem I am having is that I need to check if the PAM module is
>>> installed before making the changes and revert them if it is removed. I
>>> know I can write a custom fact, but on the 0.25 version a custom fact
>>> required both puppet.conf edits and a bounce of the agent. I haven't tried
>>> on the later versions, but I remain gun shy,
>>>
>>> Ideally I would run an execute to check the module and only do the
>>> changes if the PAM module is in place. I haven't figured out how to do that
>>> yet with templates.
>>>
>>> Has anyone else figured out the least invasive way to do this. Aka no
>>> custom facts?
>>>
>>> Do I need to just knuckle down and learn enough Ruby to have it
>>> determine if the package is set and use one variable, if not the other?
>>>
>>> I am still new to Puppet coding in Puppet 4, well in general too, when
>>> getting into the

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[HPUX_PUPPET]

Thanks Rob!

I am sort of "starting fresh" so I have a lot of latitude here. The way it 
was done before was shoddy and required a lot of files, so I am trying to 
reduce them. 

I will go back to investigating a custom fact.  I have used them in the 
past, but the problem was more related to needing to manually go to each 
host to restart puppet so it would recognize that a fact had been added. 

Unfortunately installing PAM is less the issue as having customized lines 
that need to be added to the top of the files for servers using the 3rd 
party AD authentication for boxes where it is installed. As they had 
mandatory require lines, if the files are not there, we are locked out. 
Currently we a file param to create the needed files in temp on all boxes 
and then if the software was installed, we would switch files. Trying to 
keep it less kludgy so I was seeing if Puppet could use an RPM list from 
the host to check. A custom fact seems the best way to go here. 


On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:
>
> I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you 
> are stair stepping or starting fresh), they mostly "just work". Throw them 
> in a module and poof, agents get them on the next run, and they're 
> processed before the catalog compilation of that run so they take effect 
> immediately. Learning Just Enough Ruby(TM) also should not make you too 
> shy. A long time ago, I wrote a sample custom fact that parses a hostname 
> with a regex and grabs a portion of the string (
> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/lib/facter/puppet_role.rb)
>  
> - if you are comfortable with regex, you can probably pick up the minimal 
> ruby required to understand the rest of it. It wouldn't be too difficult to 
> add a system() call to rpm and check the return code.
>
> All that said, perhaps instead of using a fact, you could use ordering 
> within your puppet manifest, to implement the PAM module first, THEN update 
> the config via template afterward. This could be as simple as this:
>
>   package{'pam-additional-module':
> ensure => present,
>   } ->
>   file{'pam-additional-module-config':
> ensure => present,
> path => /etc/pam.d/additional.conf,
> contents => template('profile/pam/additional.conf.erb'),
>   }
>
> This would install the package 'pam-additional-module', then install a 
> configuration file for it based on an ERB template. Just an example you can 
> adapt. I hope that helps!
>
>
> Rob Nelson
> rnel...@gmail.com 
>
> On Tue, Sep 13, 2016 at 2:10 PM, HPUX_PUPPET  > wrote:
>
>> I am moving from Puppet 0.25 to Puppet 4.  In doing so I am re-writing a 
>> lot of the modules to work better than what I inherited. 
>>
>> So my current issue I am trying to figure out is how to update PAM 
>> variables based on what external 3rd party authentication package we have 
>> installed on that server. The old method that had been employed was to use 
>> an exec to push a file with the correct settings.  I am trying to do it via 
>> a template. 
>>
>> The problem I am having is that I need to check if the PAM module is 
>> installed before making the changes and revert them if it is removed. I 
>> know I can write a custom fact, but on the 0.25 version a custom fact 
>> required both puppet.conf edits and a bounce of the agent. I haven't tried 
>> on the later versions, but I remain gun shy, 
>>
>> Ideally I would run an execute to check the module and only do the 
>> changes if the PAM module is in place. I haven't figured out how to do that 
>> yet with templates. 
>>
>> Has anyone else figured out the least invasive way to do this. Aka no 
>> custom facts?
>>
>> Do I need to just knuckle down and learn enough Ruby to have it determine 
>> if the package is set and use one variable, if not the other? 
>>
>> I am still new to Puppet coding in Puppet 4, well in general too, when 
>> getting into the weeds like this. I would assume there is a simple think 
>> like below. (Notes this is probably not correct puppet code, just a 
>> pseudocode example) 
>>  
>> if ( ! exec { check_package: 
>>   path => "/usr/bin:/bin:/sbin:/usr/sbin",   
>>   command => "rpm -q ",
>>   } ) { 
>>  $extra_lines = [ 
>>  'blah blak', 
>>  'blah',
>>  ]
>>}
>>
>> Think is I just don't have enough skill yet to make it work on my own 
>> yet, so I am reaching out to see if someone already figured this out as I 
>> keep hammering on it. 
>>
>> Thanks! 
>>  
>>
>> -- 
>> 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/fd5cb2f3-8ab1-4c0e-8134-f8e5ec49c1ac%40googlegroups.com
>>  
>> 

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Rob Nelson]

I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you are
stair stepping or starting fresh), they mostly "just work". Throw them in a
module and poof, agents get them on the next run, and they're processed
before the catalog compilation of that run so they take effect immediately.
Learning Just Enough Ruby(TM) also should not make you too shy. A long time
ago, I wrote a sample custom fact that parses a hostname with a regex and
grabs a portion of the string (
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/lib/facter/puppet_role.rb)
- if you are comfortable with regex, you can probably pick up the minimal
ruby required to understand the rest of it. It wouldn't be too difficult to
add a system() call to rpm and check the return code.

All that said, perhaps instead of using a fact, you could use ordering
within your puppet manifest, to implement the PAM module first, THEN update
the config via template afterward. This could be as simple as this:

  package{'pam-additional-module':
ensure => present,
  } ->
  file{'pam-additional-module-config':
ensure => present,
path => /etc/pam.d/additional.conf,
contents => template('profile/pam/additional.conf.erb'),
  }

This would install the package 'pam-additional-module', then install a
configuration file for it based on an ERB template. Just an example you can
adapt. I hope that helps!


Rob Nelson
rnels...@gmail.com

On Tue, Sep 13, 2016 at 2:10 PM, HPUX_PUPPET  wrote:

> I am moving from Puppet 0.25 to Puppet 4.  In doing so I am re-writing a
> lot of the modules to work better than what I inherited.
>
> So my current issue I am trying to figure out is how to update PAM
> variables based on what external 3rd party authentication package we have
> installed on that server. The old method that had been employed was to use
> an exec to push a file with the correct settings.  I am trying to do it via
> a template.
>
> The problem I am having is that I need to check if the PAM module is
> installed before making the changes and revert them if it is removed. I
> know I can write a custom fact, but on the 0.25 version a custom fact
> required both puppet.conf edits and a bounce of the agent. I haven't tried
> on the later versions, but I remain gun shy,
>
> Ideally I would run an execute to check the module and only do the changes
> if the PAM module is in place. I haven't figured out how to do that yet
> with templates.
>
> Has anyone else figured out the least invasive way to do this. Aka no
> custom facts?
>
> Do I need to just knuckle down and learn enough Ruby to have it determine
> if the package is set and use one variable, if not the other?
>
> I am still new to Puppet coding in Puppet 4, well in general too, when
> getting into the weeds like this. I would assume there is a simple think
> like below. (Notes this is probably not correct puppet code, just a
> pseudocode example)
>
> if ( ! exec { check_package:
>   path => "/usr/bin:/bin:/sbin:/usr/sbin",
>   command => "rpm -q ",
>   } ) {
>  $extra_lines = [
>  'blah blak',
>  'blah',
>  ]
>}
>
> Think is I just don't have enough skill yet to make it work on my own yet,
> so I am reaching out to see if someone already figured this out as I keep
> hammering on it.
>
> Thanks!
>
>
> --
> 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/fd5cb2f3-8ab1-4c0e-8134-f8e5ec49c1ac%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/CAC76iT-ONfsSvxegE75WTO8BLm%3D4jTTORF7k3Vr5UE3RW-foVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.