Re: [Puppet Users] Telly: Nagios types moving into Module

[Kelsey Hightower]

On Friday, April 13, 2012 3:06:52 PM UTC-4, Ashley Penney wrote:
>
> I think that would be OK.  I'm actually fairly nervous about this new move 
> towards dragging
> more and more out of the core into modules.  It wouldn't be so bad if 
> Puppet had a proper
> "packaging system" that handled dependencies and so forth, but as it 
> stands I'm just worried
> about reaching a situation where we're constantly telling people in 
> #puppet "oh, well first
> you need to get stdlib, nagios, yum, this, that, etc, that's why you can't 
> do this".
>

Newer versions of Puppet include an updated module tool that handles 
dependencies and some other niceties: Check out The Puppet Module Tool 
Screencast 
 

>
> However assuming this is going ahead then I think the error message should 
> probably for
> now tell the user that they've been moved AND spit out an appropriate 
> commandline to
> immediately import the module to the right place.
>
> On Fri, Apr 13, 2012 at 1:55 PM, Michael Stahnke 
> wrote:
>
>> For the next major Puppet version, code-named Telly, we have some
>> changes coming.  This is the first in a series of emails around these
>> changes and may require some input from the community.
>>
>> For Telly, the nagios types will be moved into a module.  This allows
>> them to be iterated on in isolation from the rest of Puppet's core
>> release cycle and process. In the future we have plans to move several
>> other types into modules that can be individually maintained,
>> improved, tested and used.
>>
>> The module for Nagios will be available on the Forge.
>>
>> The upgrade path is the thing we need some feedback about.  The basic
>> steps to upgrade would be to setup a Telly master, and then install
>> the Nagios module via the Puppet Module Tool, which ships integrated
>> with 2.7.13+ and Telly.
>>
>> The only caveat with this is that if, in the past, you were relying on
>> the Nagios types and forget to install that module (or are unable to
>> for some reason), you would get a failure.  The best proposal we could
>> come up with was to have the platform team add some code that lets the
>> user know that the Nagios types have moved. This basically moves this
>> into a 'fail-well' state.  We'll try to provide the best information
>> possible to the end-user about what is going on.
>>
>> Is that an acceptable path moving forward?  Comments and discussion 
>> welcome.
>>
>>
>> Mike Stahnke
>> Community Manager
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> 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/-/87YHcX_tf9UJ.
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] Telly: Nagios types moving into Module

[Walter Heck]

Well, i think there's a big difference between things that are
standard in a linux distro and modules that are 3rd party software
like nagios.
Besides I think this is all adressed by what Nigel just mentioned: the
moduel tool does dependency stuff starting with Telly.

cheers,

Walter

On Mon, Apr 16, 2012 at 11:53, Gabriel Filion  wrote:
> On 12-04-13 03:06 PM, Ashley Penney wrote:
>> I'm actually fairly nervous about this new move towards dragging
>> more and more out of the core into modules.  It wouldn't be so bad if
>> Puppet had a proper
>> "packaging system" that handled dependencies and so forth, but as it
>> stands I'm just worried
>> about reaching a situation where we're constantly telling people in
>> #puppet "oh, well first
>> you need to get stdlib, nagios, yum, this, that, etc, that's why you
>> can't do this".
>
> humm I must agree with this.
>
> Since the types by themselves are not a module per-se, could it be
> better to package them in the same manner as the core is packaged, and
> made available through the same resources?
>
> so then, people could install those with gem, apt or yum. (and easily
> require those automatically from actual modules)
>
> --
> Gabriel Filion
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> 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.
>



-- 
Walter Heck

--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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] Telly: Nagios types moving into Module

[Gabriel Filion]

On 12-04-13 03:06 PM, Ashley Penney wrote:
> I'm actually fairly nervous about this new move towards dragging
> more and more out of the core into modules.  It wouldn't be so bad if
> Puppet had a proper
> "packaging system" that handled dependencies and so forth, but as it
> stands I'm just worried
> about reaching a situation where we're constantly telling people in
> #puppet "oh, well first
> you need to get stdlib, nagios, yum, this, that, etc, that's why you
> can't do this".

humm I must agree with this.

Since the types by themselves are not a module per-se, could it be
better to package them in the same manner as the core is packaged, and
made available through the same resources?

so then, people could install those with gem, apt or yum. (and easily
require those automatically from actual modules)

-- 
Gabriel Filion

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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: Developing a module: Use it from the current directory?

[Wil Cooley]

On Apr 12, 4:01 pm, Michael Elsdörfer  wrote:
> In general, the loading/import/namespacing mechanism is really something
> that I cannot wrap my head around, even after reading the relevant sections
> in the documentation.
>
> Specifically, I'm trying to put together a module. I believe I have the
> correct module structure:
>
> $ find
> .
> ./test.pp
> ./graphite
> ./graphite/manifests
> ./graphite/manifests/init.pp
> ./graphite/files
> ./graphite/files/local_settings.py

The style guide suggests a 'tests' subdirectory within the module and
hints that the test manifests should be named parallel to the module
manifests (or classes/defines):

http://docs.puppetlabs.com/guides/style_guide.html#tests

But I don't think that's the source of your trouble.

> The test.pp file looks like this:
>
>       include graphite
>
> This will not find the module I have placed in the same directory. If I
> import the module explicitly, it still does not work:
>
>       import 'graphite'
>       include graphite

You're assuming that modules load relative to the manifest that uses
them or something like that; they do not--only 'import' does that, as
you've found, but import doesn't know anything about the special
structure within the module, which is why you have to do the part
below:

> This does work in sofar as that the script runs a good while:
>
>       import 'graphite/manifests/init.pp'
>       include graphite
>
> However, in that case, it isn't able to resolve puppet:// urls:
>
>       Could not evaluate: Could not retrieve information from environment
> production source(s)
>
> The only way I can get this to work is:
>
>       sudo puppet apply --modulepath=. test.pp
>
> Is that right? Shouldn't there be a simpler way?

Modules always load relative to _modulepath_ and module-loading knows
where to find manifests, files and templates within the module.

What you've done is pretty much what I always do, except I use the
fully-qualified path to my working copy:

  puppet apply --modulepath=$HOME/work/puppet/modules ...

This makes it easier to work from my command history (I should
probably define a shell alias, I guess).

There is nothing special about the top-level module directory in
module path, except that your module must be a subdirectory. I was
doing work recently on a module outside of my $HOME/work/puppet repo,
so the module itself was in $HOME/work/foo and I was able to use $HOME/
work as the modulepath.

Wil

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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: Need puppet module for condition copy

[Wil Cooley]

On Apr 13, 10:49 am, Munna S <19.mu...@gmail.com> wrote:
> I followed your steps. now i am getting below error
>
> Apr 13 17:42:44 pil-vm-pup-01 puppet-master[7899]: Could not find class
> dev_jboss_jeeva for vm-jeeva2.aircell.prod at

...

> i have jeeva_base.pp file under /etc/puppet/manifests/nodes and below is
> its content
> 
> node jeeva_base {
>         include dev_jboss_jeeva}
>
> --
>
> also i have a another .pp file by name vm-jeeva2 under
> /etc/puppet/manifests/nodes and below is its content. we have seperate .pp
> file for each server name. one server is vm-jeeva2.
> --
> node vm-jeeva2 inherits jeeva_base {}
>
> 
>
> what could be the problem ?

Where is the class dev_jboss_jeeva defined? You mentioned above an
'init.pp', which would be usual if you were using modules, but it does
not seem like you are using modules.

It sounds like the problem you are having is wholly outside of the
complicated machinations of what you're trying to do. It looks more
like you have a much simpler class-loading problem.

Here are a few things to try:
  * Comment out all of the stuff from dev_jboss_jeeva and replace it
with a "warning" function call, to log that everything is working
right:
  class dev_jboss_jeeva {
warning("dev_jboss_jeeva has successfully loaded")
  }
  * Copy your class dev_jboss_jeeva { ... } right before the "node
jeeva_base" and see if you see your warning message (I suggest warning
instead of info because info sometimes requires using --verbose on the
command line; warning will always show):
  class dev_jboss_jeeva {
warning("dev_jboss_jeeva was here")
  }
  node jeeva_base {
include dev_jboss_jeeva
  }

If you see the message with the class defined right before the node,
but not wherever else you have it, then you know the problem is that
it is unable to actually find the class and you should give specifics
about that instead.

Wil

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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] New CA, why do clients with old certs still work?

[Nigel Kersten]

On Fri, Apr 13, 2012 at 11:40 AM, Chip Schweiss wrote:

> I'm in the process of scalling my puppet master to two server with a
> separate CA.   My plan was to establish a new CA and reissue
> certificates.   Part way through the process I noticed a behavior that
> seems a bit alarming.
>
> With one of my clients pointing to the new CA and new Puppetmaster but
> with the old certificate I ran a 'puppetd --test --server
> puppet01.mydomain'
>
> I was expecting it to fail validation and then regenerate the client
> certificate.  However it ran without error.
>
> Thinking maybe it's still hitting the orginal CA, I backed-up and wiped
> the ssl dir on the puppetmaster and restarted the pupetmaster to generate a
> new CA.   The client still works.  There are no signed certificates for
> this client on either puppetmaster or CA now and it still runs.
>

Are you sure you're wiping the SSL dir that is actually in use? The master
isn't being started with --no-ca and you have another CA with autosign on?


>
> Am I missing something about how the puppetmaster decides it's okay to
> talk to a client, or is all the security simply on the client side, and the
> puppetmaster trusts any puppet client?
>

The agent and master need certs signed by the same CA. Are you positive
this wasn't the case? What puppet version?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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] Telly: Nagios types moving into Module

[Nigel Kersten]

On Fri, Apr 13, 2012 at 12:06 PM, Ashley Penney  wrote:

> I think that would be OK.  I'm actually fairly nervous about this new move
> towards dragging
> more and more out of the core into modules.  It wouldn't be so bad if
> Puppet had a proper
> "packaging system" that handled dependencies and so forth, but as it
> stands I'm just worried
> about reaching a situation where we're constantly telling people in
> #puppet "oh, well first
> you need to get stdlib, nagios, yum, this, that, etc, that's why you can't
> do this".
>

It's important to note here that the version of the module tool we're
talking about does indeed handle dependencies automatically, although prior
versions didn't.




>
> However assuming this is going ahead then I think the error message should
> probably for
> now tell the user that they've been moved AND spit out an appropriate
> commandline to
> immediately import the module to the right place.
>
> On Fri, Apr 13, 2012 at 1:55 PM, Michael Stahnke 
> wrote:
>
>> For the next major Puppet version, code-named Telly, we have some
>> changes coming.  This is the first in a series of emails around these
>> changes and may require some input from the community.
>>
>> For Telly, the nagios types will be moved into a module.  This allows
>> them to be iterated on in isolation from the rest of Puppet's core
>> release cycle and process. In the future we have plans to move several
>> other types into modules that can be individually maintained,
>> improved, tested and used.
>>
>> The module for Nagios will be available on the Forge.
>>
>> The upgrade path is the thing we need some feedback about.  The basic
>> steps to upgrade would be to setup a Telly master, and then install
>> the Nagios module via the Puppet Module Tool, which ships integrated
>> with 2.7.13+ and Telly.
>>
>> The only caveat with this is that if, in the past, you were relying on
>> the Nagios types and forget to install that module (or are unable to
>> for some reason), you would get a failure.  The best proposal we could
>> come up with was to have the platform team add some code that lets the
>> user know that the Nagios types have moved. This basically moves this
>> into a 'fail-well' state.  We'll try to provide the best information
>> possible to the end-user about what is going on.
>>
>> Is that an acceptable path moving forward?  Comments and discussion
>> welcome.
>>
>>
>> Mike Stahnke
>> Community Manager
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> 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 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.
>



-- 
Nigel Kersten
Product Manager, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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] Supported Ruby Versions for Telly

[Daniel Pittman]

On Sun, Apr 15, 2012 at 08:29, Dan White  wrote:
> I would have no problem trying either one of these, but the PHB-objections I
> face are that these do not come from Red Hat or a "reliable source".  They
> might trust them if they came from PuppetLabs' repository, but even that is
> no guarantee.  They are inconsistently paranoid about what they will permit
> into their production environment.  They had kittens when I initially pulled
> Cobbler and Puppet from EPEL, while they build replacements for some
> packages from source and install from the source build rather than with an
> RPM.
>
> Please tell me if I understand the versioning requirements:
>    I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master.
>    The clients/agents can use ruby 1.8.5 for now.

That is spot-on.

-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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] Supported Ruby Versions for Telly

[Ashley Penney]

You might have the best luck going the route of "Well, my puppetmaster
needs RHEL6 and that's the only way it's supported" because then you get
1.8.7 from an "official source".  I completely sympathise with your
situation, having been in it before.

Your understanding is right to the best of my knowledge, I wouldn't try and
run the master on 1.8.5, but clients should work with the stock RHEL5 Ruby.

On Sun, Apr 15, 2012 at 11:29 AM, Dan White  wrote:

> I would have no problem trying either one of these, but the PHB-objections
> I face are that these do not come from Red Hat or a "reliable source".
>  They might trust them if they came from PuppetLabs' repository, but even
> that is no guarantee.  They are inconsistently paranoid about what they
> will permit into their production environment.  They had kittens when I
> initially pulled Cobbler and Puppet from EPEL, while they build
> replacements for some packages from source and install from the source
> build rather than with an RPM.
>
> Please tell me if I understand the versioning requirements:
>I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master.
>The clients/agents can use ruby 1.8.5 for now.
>
> Is that accurate ?
>
> On Apr 15, 2012, at 12:03 AM, Craig White wrote:
>
> enterprise ruby (1.8.7 only)
>
> http://www.rubyenterpriseedition.com/download.html
>
> Craig
>
>
> On Apr 15, 2012, at 12:55 AM, Gary Larizza wrote:
>
> Have you checked out the packages that Karanbir Singh has created?  They
> work fairly well --> http://centos.karan.org/el5/ruby187/
>
>
>
> On Sat, Apr 14, 2012 at 8:53 PM, Dan White  wrote:
>
>> Great to hear this, but I am now looking for a reliable way to get Ruby
>> 1.8.7 or 1.9.3 onto a RHEL-5 system.  The environment I am working still
>> has RHEL 3 and 4 machines running, and I would not hold my breath waiting
>> for transition to RHEL 6 (which does have ruby 1.8.7 in it)
>>
>> One more thing: When I say "reliable", it has to be able to convince a
>> non-technical PHB type.
>>
>> Suggestions ?
>>
>> On Apr 13, 2012, at 2:59 PM, Michael Stahnke wrote:
>>
>> > Puppet Labs is happy to announce full support for Ruby 1.9.3 will be
>> part of
>> > the next major release of Puppet, codenamed Telly.  Ruby 1.8.7 and
>> 1.9.3 are
>> > considered the primary supported Ruby versions, on all platforms
>> including
>> > Unix, Linux, Windows, and MacOS-X.  Ruby 1.8.5 is also supported, on
>> the agent
>> > only.
>> >
>> > The Puppet 2.7 series featured initial support for the Ruby 1.9 series,
>> and we
>> > are happy to see that work completed and brought forward to full
>> production
>> > support in the forthcoming release.
>> >
>> > Other Ruby versions including 1.8.6, 1.9.1, and 1.9.2 are not officially
>> > supported. Ruby implementations other than the "MRI" series are not
>> officially
>> > supported. We will accept patches that fix issues on other (non MRI)
>> > Ruby systems.
>> >
>> > 1.9.3 was selected due to its inclusion in Fedora 17 (Beefy Miracle) and
>> > Ubuntu Precise Pangolin.
>> >
>> > Previews of Telly should be available in May. If you'd like to see some
>> of the
>> > changes happening today, you are also welcome to run Puppet's master
>> branch.
>> >
>> > If you have questions or concerns, feel free to respond here.
>> >
>> > Mike Stahnke
>> > Community Manager
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> 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.
>>
>>
>
>
> --
>
> Gary Larizza
> Professional Services Engineer
> Puppet Labs
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> 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 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 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] Supported Ruby Versions for Telly

[Dan White]

I would have no problem trying either one of these, but the PHB-objections I 
face are that these do not come from Red Hat or a "reliable source".  They 
might trust them if they came from PuppetLabs' repository, but even that is no 
guarantee.  They are inconsistently paranoid about what they will permit into 
their production environment.  They had kittens when I initially pulled Cobbler 
and Puppet from EPEL, while they build replacements for some packages from 
source and install from the source build rather than with an RPM.

Please tell me if I understand the versioning requirements:
   I need ruby 1.8.7 or 1.9.3 on the machine acting as Puppet Master.
   The clients/agents can use ruby 1.8.5 for now.

Is that accurate ?

On Apr 15, 2012, at 12:03 AM, Craig White wrote:
> enterprise ruby (1.8.7 only)
> 
> http://www.rubyenterpriseedition.com/download.html
> 
> Craig

On Apr 15, 2012, at 12:55 AM, Gary Larizza wrote:
> Have you checked out the packages that Karanbir Singh has created?  They work 
> fairly well --> http://centos.karan.org/el5/ruby187/
> 
> 

> On Sat, Apr 14, 2012 at 8:53 PM, Dan White  wrote:
> Great to hear this, but I am now looking for a reliable way to get Ruby 1.8.7 
> or 1.9.3 onto a RHEL-5 system.  The environment I am working still has RHEL 3 
> and 4 machines running, and I would not hold my breath waiting for transition 
> to RHEL 6 (which does have ruby 1.8.7 in it)
> 
> One more thing: When I say "reliable", it has to be able to convince a 
> non-technical PHB type.
> 
> Suggestions ?
> 
> On Apr 13, 2012, at 2:59 PM, Michael Stahnke wrote:
> 
> > Puppet Labs is happy to announce full support for Ruby 1.9.3 will be part of
> > the next major release of Puppet, codenamed Telly.  Ruby 1.8.7 and 1.9.3 are
> > considered the primary supported Ruby versions, on all platforms including
> > Unix, Linux, Windows, and MacOS-X.  Ruby 1.8.5 is also supported, on the 
> > agent
> > only.
> >
> > The Puppet 2.7 series featured initial support for the Ruby 1.9 series, and 
> > we
> > are happy to see that work completed and brought forward to full production
> > support in the forthcoming release.
> >
> > Other Ruby versions including 1.8.6, 1.9.1, and 1.9.2 are not officially
> > supported. Ruby implementations other than the "MRI" series are not 
> > officially
> > supported. We will accept patches that fix issues on other (non MRI)
> > Ruby systems.
> >
> > 1.9.3 was selected due to its inclusion in Fedora 17 (Beefy Miracle) and
> > Ubuntu Precise Pangolin.
> >
> > Previews of Telly should be available in May. If you'd like to see some of 
> > the
> > changes happening today, you are also welcome to run Puppet's master branch.
> >
> > If you have questions or concerns, feel free to respond here.
> >
> > Mike Stahnke
> > Community Manager
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> 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.
> 
> 
> 
> 
> -- 
> 
> Gary Larizza
> Professional Services Engineer
> Puppet Labs
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> 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 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.