[Puppet Users] Correct way to handle node-specific variable values in puppet 2.7

[Jon Schewe]

I saw a post a little while back about this, but didn't see the
details of the solution. So I'm posting to see if someone can explain
to me the correct way to do this in puppet 2.7+.

I have a variable "ldap_server" that is used inside some templates.
Some of my nodes use ldap1.company.com an some use ldap2.company.com.
So in puppet 2.6 and earlier I have:

node A {
    ldap_server = "ldap1.company.com"
    include ldap_config
}

node A {
    ldap_server = "ldap2.company.com"
    include ldap_config
}

I understand that in 2.7 this behavior is deprecated because of how
variables are looked for and this behavior will stop working in 2.8.
So what is the correct way to handle this in 2.7?

Thank you.

--
Jon Schewe | http://mtu.net/~jpschewe

-- 
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] can we avoid notify/subscribe firing on a mode change?

[Eric Shamow]

Jo,

Let's not make this personal.  You don't know how old I am or what 
infrastructures I've managed.

You don't need to use Hiera.  You can use any data lookup tool you like to do 
the same thing.

What you are seeing is not an official stance of any kind, it's a spontaneous 
community reaction.  People aren't agreeing with you, which means you aren't 
arguing effectively.

Instead of making the case that someone else should do this, I recommend that 
you code up a solution and issue a pull request.  If the code looks valuable it 
can then be managed like any other feature or code request in Puppet.  

Clearly the community is not crying out for the solution as you've enunciated 
it.  Maybe you've enunciated it poorly.  In that case, write something to fix 
it and some demo usage.  Code wins arguments.

-Eric 

-- 

Eric Shamow
Professional Services
http://puppetlabs.com/
(c)631.871.6441


On Monday, June 18, 2012 at 5:07 PM, Jo Rhett wrote:

> Right, sure.  Instead of 18 lines of puppet policy that do exactly what I 
> need, I should instead go create an infrastructure based around a barely 
> documentation and SLOW part of puppet.  Because who wants finer granularity 
> for your controls, when you could implement a huge infrastructure instead?
> 
> I take it you are a bit too young to have watched companies go out and 
> implement Active Directory to solve a minor technical problem, aren't you?  
> There is no value in implementing an infrastructure with its own requirements 
> for redundancy and its own dependancies to solve something you can code in an 
> hour.
> 
> On Jun 18, 2012, at 4:27 PM, Eric Shamow wrote:
> > No - if it's that small and simple, the data bout which host is in which 
> > should be in your source of truth, CMDB, etc - and Puppet should read that 
> > data and determine which attribute or set of attributes (or resources) is 
> > applied based on that.
> > 
> > You can do this today with hiera and conditionals.
> > 
> > -- 
> > 
> > Eric Shamow
> > Professional Services
> > http://puppetlabs.com/
> > (c)631.871.6441
> >  
> > 
> > 
> > -- 
> > 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 
> > (mailto:puppet-users@googlegroups.com).
> > To unsubscribe from this group, send email to 
> > puppet-users+unsubscr...@googlegroups.com 
> > (mailto:puppet-users+unsubscr...@googlegroups.com).
> > For more options, visit this group at 
> > http://groups.google.com/group/puppet-users?hl=en.
> 
> -- 
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet 
> projects.
> 
> 
> 
> -- 
> 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 
> (mailto:puppet-users@googlegroups.com).
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com 
> (mailto: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] Service Puppetmaster being monitored by Nagios

[Brian Gupta]

On Mon, Jun 18, 2012 at 10:22 AM, Wendell Araujo
 wrote:
> Good morning!
>
> I have a server running Nagios and would like to monitor the service in my
> puppet server puppetmaster. Has anyone managed to do this?
>
> grateful
>
> Wendell

So this doesn't exactly answer your question, but it is a pattern that
may be of use. So we push out a managed file to all clients that gets
updated everytime we make a commit to the puppetcode base (git post
commit hook), and have a corresponding nagios check that confirms that
the version of the file on the puppet master is the same as on the
client. This tells us if anything is broken in the loop, including a
nonfunctional puppetmaster.

>
> --
> 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] can we avoid notify/subscribe firing on a mode change?

[Denmat]

Okay back to the original problem. It's become a bit hard to follow.

Without code change to puppet you're stumped. But without knowing your systems 
a combination of package based deployments and excluding mode or owner maybe 
will get you by?

But with puppet code change, would a way of doing what you are proposing be 
something like this:

file { title:
  owner => name,
  mode => 0755,
  content => content,
  notify.=> service[name],
  notify_on => ['owner', 'content'],
}

Now I don't know how easy that is to code into puppet, but I think that would 
sound like a useful feature to me.

Regards,
Den




On 19/06/2012, at 10:11, "Shawn"  wrote:

> Brutal you are. 
> -yoda
> Sent via BlackBerry
> From: Jo Rhett 
> Sender: puppet-users@googlegroups.com
> Date: Mon, 18 Jun 2012 17:07:21 -0700
> To: 
> ReplyTo: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode 
> change?
> 
> Right, sure.  Instead of 18 lines of puppet policy that do exactly what I 
> need, I should instead go create an infrastructure based around a barely 
> documentation and SLOW part of puppet.  Because who wants finer granularity 
> for your controls, when you could implement a huge infrastructure instead?
> 
> I take it you are a bit too young to have watched companies go out and 
> implement Active Directory to solve a minor technical problem, aren't you?  
> There is no value in implementing an infrastructure with its own requirements 
> for redundancy and its own dependancies to solve something you can code in an 
> hour.
> 
> On Jun 18, 2012, at 4:27 PM, Eric Shamow wrote:
>> No - if it's that small and simple, the data bout which host is in which 
>> should be in your source of truth, CMDB, etc - and Puppet should read that 
>> data and determine which attribute or set of attributes (or resources) is 
>> applied based on that.
>> 
>> You can do this today with hiera and conditionals.
>> 
>> -- 
>> 
>> Eric Shamow
>> Professional Services
>> http://puppetlabs.com/
>> (c)631.871.6441
>>  
>> 
>> 
>> -- 
>> 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.
> 
> -- 
> Jo Rhett
> Net Consonance : net philanthropy to improve open source and internet 
> projects.
> 
> 
> 
> -- 
> 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] can we avoid notify/subscribe firing on a mode change?

[Shawn]

Brutal you are. 
-yoda
Sent via BlackBerry

-Original Message-
From: Jo Rhett 
Sender: puppet-users@googlegroups.com
Date: Mon, 18 Jun 2012 17:07:21 
To: 
Reply-To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode 
change?

Right, sure.  Instead of 18 lines of puppet policy that do exactly what I need, 
I should instead go create an infrastructure based around a barely 
documentation and SLOW part of puppet.  Because who wants finer granularity for 
your controls, when you could implement a huge infrastructure instead?

I take it you are a bit too young to have watched companies go out and 
implement Active Directory to solve a minor technical problem, aren't you?  
There is no value in implementing an infrastructure with its own requirements 
for redundancy and its own dependancies to solve something you can code in an 
hour.

On Jun 18, 2012, at 4:27 PM, Eric Shamow wrote:
> No - if it's that small and simple, the data bout which host is in which 
> should be in your source of truth, CMDB, etc - and Puppet should read that 
> data and determine which attribute or set of attributes (or resources) is 
> applied based on that.
> 
> You can do this today with hiera and conditionals.
> 
> -- 
> 
> Eric Shamow
> Professional Services
> http://puppetlabs.com/
> (c)631.871.6441
>  
> 
> 
> -- 
> 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.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

Right, sure.  Instead of 18 lines of puppet policy that do exactly what I need, 
I should instead go create an infrastructure based around a barely 
documentation and SLOW part of puppet.  Because who wants finer granularity for 
your controls, when you could implement a huge infrastructure instead?

I take it you are a bit too young to have watched companies go out and 
implement Active Directory to solve a minor technical problem, aren't you?  
There is no value in implementing an infrastructure with its own requirements 
for redundancy and its own dependancies to solve something you can code in an 
hour.

On Jun 18, 2012, at 4:27 PM, Eric Shamow wrote:
> No - if it's that small and simple, the data bout which host is in which 
> should be in your source of truth, CMDB, etc - and Puppet should read that 
> data and determine which attribute or set of attributes (or resources) is 
> applied based on that.
> 
> You can do this today with hiera and conditionals.
> 
> -- 
> 
> Eric Shamow
> Professional Services
> http://puppetlabs.com/
> (c)631.871.6441
>  
> 
> 
> -- 
> 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.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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] can we avoid notify/subscribe firing on a mode change?

[Shawn]

--Original Message--
From: Felix Frank
Sender: puppet-users@googlegroups.com
To: puppet-users@googlegroups.com
ReplyTo: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] can we avoid notify/subscribe firing on a mode 
change?
Sent: Jun 14, 2012 7:18 AM

On 06/14/2012 12:39 PM, Jo Rhett wrote:
>> What you're suggesting is a differentiation that has never existed in
>> this context (afaik). I'm not sure I feel good about opening this door -
>> I can easily see it become a gateway for lots of unintended effects to
>> trip users up.
> 
> How so?  The variable would allow the user to be explicit. As it stands
> now, I suspect most people would be surprised.

Maybe so, but if nothing else, current behaviour is very consistent,
which I consider a very redeeming quality.

One problem scenario I can see is users defining defaults for this
parameter, with the usual scoping behaviors that can easily confuse
(especially new) users.

> I am also very disconcerted about the issues involved in setting up new
> files.  You can never, ever, EVER change the mode of a newly installed
> file without restarting services on all existing machines.  That doesn't
> make any sense.

I don't really understand your scenario. There is a new config file for
service X. It gets installed from a package, presumably the X package
itself. How are service restarts immediately after package installation
problematic?

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


Sent via BlackBerry

-- 
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

On Jun 18, 2012, at 4:41 PM, Wolf Noble wrote:
> No, it's not the easiest way to break your environment. but it is a direct 
> line to future obfuscated breakage, red herrings, and new and exciting ways 
> to waste lots of engineers' time trying to suss out what in the the last N 
> changes broke $package.
> 
> Not taking that into account will arguably lead one to making bad design 
> choices.  Aren't we supposed to be lazy and try to NOT shoot ourselves in the 
> foot unexpectedly?

First of all, do you know this environment better than I do?  Are you in a 
position to tell us that this risk is worse than another? I can assure you that 
the risk of using a completely different configuration manager/ecosystem side 
by side with puppet is much risker than using the fine-grained control to do 
exactly what we know and have tested to work properly through an extensive QA 
process.

I am amazed that people are very interested in telling me that I should 
implement an external system to replace puppet, rather than allow fine-grained 
control of triggers.  This is simply amazing.  Sure, it's much better to run 
two different configuration management systems interlaced with each other.  
Nothing could go wrong with that, right? *headdesk*

>> Same software, same management functions, same configs… just a different 
>> permissions change on new installations. Should I really duplicate the 
>> entire module, and manage all changes in both places?  And forever try to 
>> manage which host should be in which generation?
> 
> There's many ways of doing this…  A case statement tied to a version number, 
> or some other fact will get you this..
> Aren't you pretty clearly stating that this old generation IS different than 
> the next generation? How is puppet supposed to KNOW the difference between 
> the two?

It isn't. That's the point.  At the puppet level there is absolute no 
difference.  We simply want new installations to have the new permissions. Old 
installations are going to be upgraded by hand, outside of puppet. We desire a 
period of overlap, where new installations can be set up correctly with the new 
permissions WITHOUT having the older installations fall over.

During this overlap period, any change to the installations will be applied to 
both old and new.

Having "replace => false" not apply to mode, owner and group would meet our 
needs -- but the general-purpose fix could apply to a lot more situations.

> I've yet to see a satisfactory implementation of 'do what I mean, not what I 
> say'.. but then again, I think that's why we're driving the computers and not 
> the other way around…

This has nothing to do with "do what I mean".  I am being very, very specific 
about what I say.  I want to be more specific than puppet allows me, and people 
are fighting this idea all over the place.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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] can we avoid notify/subscribe firing on a mode change?

[Wolf Noble]

On Jun 18, 2012, at 6:04 PM, Jo Rhett wrote:

> On Jun 18, 2012, at 1:57 PM, Wolf Noble wrote:
>>> Well, a in the service of b -- but as a general point, I think that every 
>>> notify/subscribe should be tune-able as to which things changing will cause 
>>> the action to take place.
>>
>> Not to continue this thread longer than it needs to go, but wouldn't your 
>> suggested paradigm permit you to bite yourself in the following scenario:
>>  - change the ownership or mode of a file to the point that the required 
>> application could no longer access the file
>>  - exclude this change from notifying or triggering the application that the 
>> permissions or ownership of its' config file have changed.
>>  This change will go unnoticed until:
>> o Some random point in time in the future wherein the service "should" 
>> restart according to the method you propose.
>> o Some part of the application needs to re-read it's configuration file
>> o The server reboots
>> Suddenly things don't work. You don't have a smoking gun for the culprit 
>> change as that "clean" deployment happened [hours,days,weeks] ago with some 
>> other "unrelated" change by some other team that this service was set to 
>> ignore.
>
> I do believe I can shoot myself in the foot a dozen different ways that 
> puppet does allow me to do:
>* break the configuration in the change
>* fail to restart the service
>* break some other dependancy
> …etc
>
> The short version is this is nowhere close to the easiest way to bag the 
> service or host. I can do it dozens of ways with puppet today.  It's my job 
> to write the policy well, and test it well, and test all its dependencies.  
> Puppet can't save me from myself.
> What would be really nice is if I can, writing my policy carefully, achieve 
> more granularity, more control. Saying that I shouldn't have finer-grained 
> control because I could bag the service makes no sense, unless this was 
> opening some new vector in which to do so.  It isn't.

No, it's not the easiest way to break your environment. but it is a direct line 
to future obfuscated breakage, red herrings, and new and exciting ways to waste 
lots of engineers' time trying to suss out what in the the last N changes broke 
$package.

Not taking that into account will arguably lead one to making bad design 
choices.  Aren't we supposed to be lazy and try to NOT shoot ourselves in the 
foot unexpectedly?

>> Just my $.02, but if a file's ownership shouldn't change,  and it belongs to 
>> a specific module, and there becomes a reason to change that ownership, 
>> without impacting existing modules, does it make sense to create a different 
>> module, and manage the dissimilar needs via that route?
>
> Same software, same management functions, same configs… just a different 
> permissions change on new installations. Should I really duplicate the entire 
> module, and manage all changes in both places?  And forever try to manage 
> which host should be in which generation?


There's many ways of doing this…  A case statement tied to a version number, or 
some other fact will get you this..
Aren't you pretty clearly stating that this old generation IS different than 
the next generation? How is puppet supposed to KNOW the difference between the 
two?

I've yet to see a satisfactory implementation of 'do what I mean, not what I 
say'.. but then again, I think that's why we're driving the computers and not 
the other way around…
oof. My laptop's out of battery… have to go plug it in…Hey… Wait a minute..




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
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] can we avoid notify/subscribe firing on a mode change?

[Eric Shamow]

On Monday, June 18, 2012 at 4:04 PM, Jo Rhett wrote:
> Same software, same management functions, same configs… just a different 
> permissions change on new installations. Should I really duplicate the entire 
> module, and manage all changes in both places?  And forever try to manage 
> which host should be in which generation?

No - if it's that small and simple, the data bout which host is in which should 
be in your source of truth, CMDB, etc - and Puppet should read that data and 
determine which attribute or set of attributes (or resources) is applied based 
on that.

You can do this today with hiera and conditionals.

--  

Eric Shamow
Professional Services
http://puppetlabs.com/
(c)631.871.6441
  

-- 
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

On Jun 18, 2012, at 1:57 PM, Wolf Noble wrote:
>> Well, a in the service of b -- but as a general point, I think that every 
>> notify/subscribe should be tune-able as to which things changing will cause 
>> the action to take place.
> 
> Not to continue this thread longer than it needs to go, but wouldn't your 
> suggested paradigm permit you to bite yourself in the following scenario:
>  - change the ownership or mode of a file to the point that the required 
> application could no longer access the file
>  - exclude this change from notifying or triggering the application that the 
> permissions or ownership of its' config file have changed.
>  This change will go unnoticed until:
> o Some random point in time in the future wherein the service "should" 
> restart according to the method you propose.
> o Some part of the application needs to re-read it's configuration file
> o The server reboots
> Suddenly things don't work. You don't have a smoking gun for the culprit 
> change as that "clean" deployment happened [hours,days,weeks] ago with some 
> other "unrelated" change by some other team that this service was set to 
> ignore.

I do believe I can shoot myself in the foot a dozen different ways that puppet 
does allow me to do:
   * break the configuration in the change
   * fail to restart the service
   * break some other dependancy
…etc

The short version is this is nowhere close to the easiest way to bag the 
service or host. I can do it dozens of ways with puppet today.  It's my job to 
write the policy well, and test it well, and test all its dependencies.  Puppet 
can't save me from myself.

What would be really nice is if I can, writing my policy carefully, achieve 
more granularity, more control. Saying that I shouldn't have finer-grained 
control because I could bag the service makes no sense, unless this was opening 
some new vector in which to do so.  It isn't.

> Just my $.02, but if a file's ownership shouldn't change,  and it belongs to 
> a specific module, and there becomes a reason to change that ownership, 
> without impacting existing modules, does it make sense to create a different 
> module, and manage the dissimilar needs via that route?


Same software, same management functions, same configs… just a different 
permissions change on new installations. Should I really duplicate the entire 
module, and manage all changes in both places?  And forever try to manage which 
host should be in which generation?

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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: 403 Forbidden with Passenger

[jbrown]

Michael,

Thanks for the quick response. I'll take a closer look at the instructions 
and see if they work in my environment. 

I appreciate the thoughtful reply.

Cheers,
Justin

On Monday, June 18, 2012 12:31:28 PM UTC-5, Michael Altfield wrote:
>
> jbrown,
>
> Sorry for not posting my solution. I've been working on this install for 
> weeks, and I *did* overcome this error, but I've had to overcome so many 
> errors, I can't recall the exact fix. iirc, the solution might have been 
> installing rubygem-rack through yum as opposed to gems.
>
> In any case, here's the commands I have come up with to successfully 
> install Puppet Master & puppet-dashboard on CentOS 6.2. (Note: this is 
> incomplete: I'm still working on getting the Inventory Service up and 
> running, and this install procedure still needs some hardening). FWIW:
>
> # run this on just the Puppet Master, which should be running CentOS 6
>
> # Generate Entropy for random-seed from Gold Image for Cert Generation
>
> wget -O /var/lib/random-seed 
> http://www.random.org/cgi-bin/randbyte?nbytes=200
> # Configure DNS
>
> echo "10.10.10.2 dashboard puppet" >> /etc/hosts
>
> # skip this if DNS is setup properly
> echo "10.10.10.3 puppetnode-01 puppetnode-01.mydomain.com" >> /etc/hosts
> echo "10.10.10.4 puppetnode-02 puppetnode-02.mydomain.com" >> /etc/hosts
> # …
> # Add Repository - yum.puppetlabs.com
>
> cat > /etc/yum.repos.d/puppetlabs.repo < [puppetlabs]
> name=puppetlabs
> enabled=1
> baseurl=http://yum.puppetlabs.com/el/6/products/x86_64/
> gpgcheck=0
>
> DELIM
> # Add Repository - EPEL
>
> rpm -ivh 
> https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
>
> # Apply Changes to yum
> yum -y update
> # Install Dependencies - yum
>
> yum -y install gcc-c++ make httpd httpd-devel mod_ssl puppet ruby-devel 
> rubygem-rack curl-devel openssl-devel zlib-devel
> # Install Dependencies - passenger
>
> # this next command tends to fail 10% of the time with "ERROR: 
> http://rubygems.org/ does not appear to be a repository". If this 
> happens, just try again in a few minutes. The website is probably 
> experiencing overload.
> gem install passenger
> passenger-install-apache2-module -a
> # Configure Puppet
>
> # create backup
> cp /etc/puppet/puppet.conf /etc/puppet/puppet.conf.`date 
> "+%Y%m%d%H%M%S"`.orig
>
> # clobber old puppet.conf
> cat > /etc/puppet/puppet.conf << DELIM
> [main]
> logdir = /var/log/puppet
> vardir = /var/lib/puppet
> confdir = /etc/puppet
> ssldir = /var/lib/puppet/ssl
> rundir = /var/run/puppet
> factpath = $vardir/lib/facter
> templatedir = $confdir/templates
>
> [master]
> certname = 12345
> dns_alt_names = puppet,dashboard,1234,12345
> ssl_client_header = SSL_CLIENT_S_DN
> ssl_client_verify_header = SSL_CLIENT_VERIFY
>
> reports = store, http
> reporturl = http://12345:8080/reports/upload
>
> [agent]
> server = dashboard
> report = true
>
> [cert]
> autosign = false
>
> DELIM
>
> # replace all instances of 12345 in puppet.conf with the FQDN
> sed -e s,12345,`hostname`,g -i /etc/puppet/puppet.conf
> # Puppet Master config.ru - Create
>
> mkdir -p /usr/share/puppet/rack/puppetmasterd
> mkdir /usr/share/puppet/rack/puppetmasterd/public
> mkdir /usr/share/puppet/rack/puppetmasterd/tmp
>
> cat > /usr/share/puppet/rack/puppetmasterd/config.ru < ARGV << "--rack"
> require 'puppet/application/master'
> run Puppet::Application[:master].run
> #eof
>
> DELIM
> # Puppet Master config.ru - Permissons 
>
> chown puppet /usr/share/puppet/rack/puppetmasterd/config.ru
> # Configure puppet-master.conf - Apache vhost
>
> cat > /etc/httpd/conf.d/puppet-master.conf << DELIM
> ## Puppetmaster Apache Vhost Configuration
>
> # Update the paths of the next 2 lines to match your installed version of 
> passenger
> LoadModule passenger_module 
> /usr/lib/ruby/gems/1.8/gems/passenger-3.0.13/ext/apache2/mod_passenger.so
> PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.13
> PassengerRuby /usr/bin/ruby
>
> ## Passenger Limits
> PassengerHighPerformance On
> PassengerMaxPoolSize 12
> PassengerPoolIdleTime 1500
> PassengerMaxRequests 1000
> PassengerStatThrottleRate 120
> RackAutoDetect Off
> RailsAutoDetect Off
>
> Listen 8140
>
> 
> ServerName puppetmaster-01.mydomain.com
>
> SSLEngine on
> SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA
>
> SSLCertificateFile /var/lib/puppet/ssl/certs/12345.pem
> SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/12345.pem
> SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
> SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem
>
> ## CRL checking should be enabled; if you have problems with
> ## Apache complaining about the CRL, disable the next line
> SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
> SSLVerifyClient optional
> SSLVerifyDepth 1
> SSLOptions +StdEnvVars
>
> ## The following client headers allow the same configuration
> ## to work with Pound.
> RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
> RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
> Request

Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

[Wolf Noble]

… Now that I'm excessively caffeinated (I'm not actually sure if that's better, 
or worse, than my previous state, but)…


On Jun 18, 2012, at 12:47 PM, Jo Rhett wrote:

> On Jun 18, 2012, at 12:55 AM, Felix Frank wrote:
>> this thread is starting to confuse me, I am no longer sure what you're
>> suggesting, precisely.
>>
>> a) Make it possible to nullify notifications under certain circumstances.
>> b) Make it possible to ignore file owner/mode for files that exist already.
>>
>> While (b) is rather tasteless to me (as is the whole "replace"
>> parameter), it is certainly well in line of what's possible today, so I
>> wouldn't object too much.
>> (a) is a nightmare I hope you're not invested in.
>
> Well, a in the service of b -- but as a general point, I think that every 
> notify/subscribe should be tune-able as to which things changing will cause 
> the action to take place.



Not to continue this thread longer than it needs to go, but wouldn't your 
suggested paradigm permit you to bite yourself in the following scenario:
  - change the ownership or mode of a file to the point that the required 
application could no longer access the file
  - exclude this change from notifying or triggering the application that the 
permissions or ownership of its' config file have changed.
  This change will go unnoticed until:
 o Some random point in time in the future wherein the service "should" 
restart according to the method you propose.
 o Some part of the application needs to re-read it's configuration file
 o The server reboots

Suddenly things don't work. You don't have a smoking gun for the culprit change 
as that "clean" deployment happened [hours,days,weeks] ago with some other 
"unrelated" change by some other team that this service was set to ignore.

That really seems, to me at least, like a huge bag of pain to drag around 
waiting to pull out simply because it's tuesday.
… I never could get the hang of tuesdays.

Just my $.02, but if a file's ownership shouldn't change,  and it belongs to a 
specific module, and there becomes a reason to change that ownership, without 
impacting existing modules, does it make sense to create a different module, 
and manage the dissimilar needs via that route?

That would at least let you know you're attempting to utilize two incompatible 
resources before doing so







This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
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] Inventory Service on RHEL - uninitalized constant ActiveRecord

[Michael Altfield]

Hi,

Has anyone had success getting the Inventory Service running in RHEL 6?

My Puppet Nodes are getting the following error:

> [root@puppetnode-01 ~]# puppetd --debug --verbose --no-daemonize
> ...
> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Could not autoload inventory_active_record: uninitialized constant 
> ActiveRecord
> ...


Here's the gems I have installed:

> [root@puppetmaster ~]# gem list
> *** LOCAL GEMS ***
> activemodel (3.0.11)
> activerecord (3.0.11)
> activesupport (3.0.11)
> arel (2.0.10)
> builder (2.1.2)
> daemon_controller (1.0.0)
> fastthread (1.0.7)
> i18n (0.5.0)
> passenger (3.0.13)
> rack (1.1.0)
> rake (0.9.2.2, 0.8.7)
> tzinfo (0.3.33)


Any help will be much appreciated!

-- 
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/-/vgw6f78APSAJ.
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

> On Monday, June 18, 2012 at 1:07 PM, Jo Rhett wrote:
>> *boggle* Um, so your configuration management system is not part of your 
>> change management implementation? That's what you just said, and it makes no 
>> sense.

On Jun 18, 2012, at 1:10 PM, Eric Shamow wrote:
> Not to speak for David but in general - the point is that they are different 
> components of an interlocking whole.

Of course they are.

> In the cases you are discussing (conflict between multiple groups working on 
> related systems) you need to implement better change control or CI.  While 
> Puppet works quite well with those technologies, we don't yet provide tooling 
> around git/svn/choose your tool VCS, nor do we provide the workflow itself.

Of course not.  My response was to people who literally, specifically told me 
to edit the policy but not apply it until the specified time.  Like "dude, stop 
puppet on that host and run it by hand later".  Works great with 5 systems, not 
so much with 500 and different teams who want puppet running for their own work.

> In terms of conflicting changes, you really need code review, CI, or 
> preferably both.  That's how large organizations handle scale.  Trying to 
> force the tool to solve development problems isn't going to work. Look at how 
> development teams solve the same problems.  They don't do it by refusing to 
> build a new daily snapshot of parts of the software.

You are singing to the choir.  You missed the point I was responding to 
originally, which was the suggestion to stop puppet on the existing hosts so I 
could deploy the policy to the new hosts without affecting the service, then 
restarting puppet on those hosts at the appropriate time.  Which is *NOT* 
applicable to any reasonable workflow.

I find it really odd that people are coming down on me about having good change 
management, in response to my comment that no reasonable change management 
system would perform the steps suggested.  Totally, completely, beating up the 
choir.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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: using hiera for node classification

[Nick Fagerlund]

On Monday, June 18, 2012 12:18:51 PM UTC-7, jon wrote:
>
>   If so, is it possible to pass in parameterized classes this way, like:
>
> user@host$ cat openstackall.yaml 2012-06-18 14:56:01 jon pts/13
> ---
> classes:
> - openstack::all: {  
>   public_address: %{ipaddress_eth0},
>   public_interface: eth0,
>   private_interface: eth1,
>   admin_email: nob...@csail.mit.edu,
>   admin_password: admin_password,
>   keystone_admin_token: keystone_admin_token,
>   nova_user_password: nova_user_password,
>   glance_user_password: glance_user_password,
>   rabbit_password: rabbit_password,
>   rabbit_user: rabbit_user,
>   libvirt_type: kvm,
>   fixed_range: 10.0.0.0/24 }
>
>
>
Alas, no -- it really is just calling the "include" function, which doesn't 
handle class parameters. 

YOUR OPTIONS:

In puppet 3.0, "include" will automatically do a heira lookup of any class 
parameters you omit, which means you can give the list of classes to 
hiera_include and then specify class parameters right below. (like 
class::parameter1: "value" class::parameter2: "value")

OR

You could use the "create_resources" function to do what you want today. 
Just have to modify the yaml slightly, because you want a hash of hashes:

---
classes:
  example::test:
parameter1: value1
  openstack::all:
public_address: %{ipaddress_eth0}
public_interface: eth0
private_interface: eth1
admin_email: nob...@csail.mit.edu
admin_password: admin_password
keystone_admin_token: keystone_admin_token
nova_user_password: nova_user_password
glance_user_password: glance_user_password
rabbit_password: rabbit_password
rabbit_user: rabbit_user
libvirt_type: kvm
fixed_range: 10.0.0.0/24

Then, in your manifest:

create_resources( 'class', hiera('classes') )

See here: 
http://docs.puppetlabs.com/references/latest/function.html#createresources

-- 
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/-/tsMyQ_Zc7OkJ.
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] can we avoid notify/subscribe firing on a mode change?

[Eric Shamow]

On Monday, June 18, 2012 at 1:07 PM, Jo Rhett wrote:
> *boggle* Um, so your configuration management system is not part of your 
> change management implementation? That's what you just said, and it makes no 
> sense.

Jo,

Not to speak for David but in general - the point is that they are different 
components of an interlocking whole.

In the cases you are discussing (conflict between multiple groups working on 
related systems) you need to implement better change control or CI.  While 
Puppet works quite well with those technologies, we don't yet provide tooling 
around git/svn/choose your tool VCS, nor do we provide the workflow itself.

In terms of conflicting changes, you really need code review, CI, or preferably 
both.  That's how large organizations handle scale.  Trying to force the tool 
to solve development problems isn't going to work.

Look at how development teams solve the same problems.  They don't do it by 
refusing to build a new daily snapshot of parts of the software.

-- 

Eric Shamow
Professional Services
http://puppetlabs.com/
(c)631.871.6441

-- 
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] How to create local puppet forge repositories

[Ryan Coleman]

On Mon, Jun 18, 2012 at 12:01 PM, Lian Zhu  wrote:
> Hi, was just wondering if there's a way to create a local forge repositories
> to host our local modules? Has anyone done that?
> I found this post, http://projects.puppetlabs.com/issues/5033.
> that was one year ago. Wondering if there's a way to do it now?
>
> Thanks.

Hi,

As Pieter mentioned, we don't currently have this capability.

I'm curious about your particular needs from a local forge. Are you
interested in hosting your own modules on the Forge for use in the
Puppet Module Tool but don't want your modules to be publicly
accessible? Any other requirements would be useful to hear about too.

Thanks!

--Ryan

-- 
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

On Jun 18, 2012, at 2:08 AM, David Schmitt wrote:
> I say "running puppet *hot* on a system *when* restarting a service might 
> create a booboo is a bad idea." Emphasis on *hot* and *when*. For both 
> emphasises, there are solutions (noop, cron, schedules, mcollective, dssh). 
> Using a different CM is not likely to solve that unless you're willing to go 
> the build-freeze-scrap route.

I'm not certain I understand your definition of "hot".  Is this normal puppet 
runs, puppet kick, etc.  It's also not clear to me why you think it's bad. I 
hear your assertation, but I don't see any explanation of why you feel it is 
bad.

For perspective, we routinely restart services while puppet is running "hot" 
(if I understood your definition there) and I'm not aware of any reason this is 
bad. Please educate me.

> The core of this runs into organizational realms like "Change Management", 
> which are not in scope for the puppet master/agent.

*boggle* Um, so your configuration management system is not part of your change 
management implementation? That's what you just said, and it makes no sense.

> At the clients I work for, Rule #1 is "do not push into production." Even 
> some of the outward-facing "test" systems have sensitive times when clients 
> are testing. Developing changes and actually applying them are two VERY 
> separate activities. You might want to look into git-flow to dis-entangle 
> development, teams, and integration.

You are either saying some incredibly obvious -- like not hacking on production 
schemas without testing -- or something that I'm not following.  For this 
thread, none of these things appear to be topical. I'm not talking about how to 
manage changes to the production puppet policies. I'm talking about when 
someday a decision is made that new installations will have different rights, 
and after that new configuration is developed, tested and confirmed -- we 
should have the option of not changing the mode for existing installations.

Right now, testing and development of that change let us to the conclusion that 
we had to remove the file from puppet entirely. Which means that it has to be 
managed by a different mechanism, which means a completely different 
configuration management system which can incorporate that idea.

This is the meat of the problem: if this is a problem puppet shouldn't be used 
to handle, are you encouraging cfengine to be installed side by side with it? 
cfengine can handle this just fine.

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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] Puppet and Ruby 1.9

[Kinzel, David]

>On Mon, Jun 18, 2012 at 10:02:10PM +0300, Ohad Levy wrote:
>> On Mon, Jun 18, 2012 at 9:32 PM, Forrie  wrote:
>> 
>> > What is the status of compatibility with Puppet 2.7.16+ and Ruby
>> > 1.9?   I searched through this group and found some older 
>posts.  I am
>> > not certain what the core issues are (and there's probably a
>> > PuppetLabs page for it, I bet).
>> >
>> 
>> afair, there is an issue with ssl requests on fedora 17 
>which is ruby 1.93.

The certificate verify issue was just recently fixed in puppet.

We've had no show-stoppers with an fairly modern puppet 2.7.x and ruby 1.9 in 
our environment.

>> 
>> Ohad
>> 
>


This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of the
intended recipient only. Any review, retransmission or dissemination of this
information by anyone other than the intended recipient is prohibited. If you
receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.

http://www.encana.com

-- 
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] Puppet and Ruby 1.9

[Stefan Schulte]

On Mon, Jun 18, 2012 at 10:02:10PM +0300, Ohad Levy wrote:
> On Mon, Jun 18, 2012 at 9:32 PM, Forrie  wrote:
> 
> > What is the status of compatibility with Puppet 2.7.16+ and Ruby
> > 1.9?   I searched through this group and found some older posts.  I am
> > not certain what the core issues are (and there's probably a
> > PuppetLabs page for it, I bet).
> >
> 
> afair, there is an issue with ssl requests on fedora 17 which is ruby 1.93.
> 
> Ohad
> 

According to redmine there are also a few other issues that might matter
for you:
http://projects.puppetlabs.com/projects/puppet/issues?query_id=107

-Stefan

-- 
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] using hiera for node classification

[jon]

Hi All,

I've been trying to use Hiera for node classification, my sit.pp is simple:

node default {
  hiera_include("classes")
}

 which has been working well with simple class definitions like:

user@host$ cat testagent.yaml2012-06-18 14:55:48 jon pts/13
---
classes:
- motd

Is anyone doing this in production?  I've seen a little about this on line 
but it seems to be mostly toy cases like the above.  If so, is it possible 
to pass in parameterized classes this way, like:

user@host$ cat openstackall.yaml 2012-06-18 14:56:01 jon pts/13
---
classes:
- openstack::all: {  
  public_address: %{ipaddress_eth0},
  public_interface: eth0,
  private_interface: eth1,
  admin_email: nob...@csail.mit.edu,
  admin_password: admin_password,
  keystone_admin_token: keystone_admin_token,
  nova_user_password: nova_user_password,
  glance_user_password: glance_user_password,
  rabbit_password: rabbit_password,
  rabbit_user: rabbit_user,
  libvirt_type: kvm,
  fixed_range: 10.0.0.0/24 }

The above doesn't work, probably because I'm simply using the wrong 
structure...

Thanks,
-Jon

ps if you saw this on the -dev list, mea culpa, auto complete misfire 
reposting here where it belongs

-- 
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/-/95mnxivvFNwJ.
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] How to create local puppet forge repositories

[Pieter van de Bruggen]

On Mon, Jun 18, 2012 at 12:01 PM, Lian Zhu  wrote:

> Hi, was just wondering if there's a way to create a local forge
> repositories to host our local modules? Has anyone done that?
> I found this post, http://projects.puppetlabs.com/issues/5033.
> that was one year ago. Wondering if there's a way to do it now?
>
> Thanks.
>
> --
> 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/-/xPOkz7w-qQwJ.
> 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.
>

Sadly, we don't have a way for you to do this yet.

-- 
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] How to create local puppet forge repositories

[Lian Zhu]

Hi, was just wondering if there's a way to create a local forge 
repositories to host our local modules? Has anyone done that? 
I found this post, http://projects.puppetlabs.com/issues/5033. 
that was one year ago. Wondering if there's a way to do it now?

Thanks.

-- 
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/-/xPOkz7w-qQwJ.
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 and Ruby 1.9

[Ohad Levy]

On Mon, Jun 18, 2012 at 9:32 PM, Forrie  wrote:

> What is the status of compatibility with Puppet 2.7.16+ and Ruby
> 1.9?   I searched through this group and found some older posts.  I am
> not certain what the core issues are (and there's probably a
> PuppetLabs page for it, I bet).
>

afair, there is an issue with ssl requests on fedora 17 which is ruby 1.93.

Ohad

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

[Puppet Users] Puppet and Ruby 1.9

[Forrie]

What is the status of compatibility with Puppet 2.7.16+ and Ruby
1.9?   I searched through this group and found some older posts.  I am
not certain what the core issues are (and there's probably a
PuppetLabs page for it, I bet).

Thanks.

-- 
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

On Jun 18, 2012, at 12:55 AM, Felix Frank wrote:
> this thread is starting to confuse me, I am no longer sure what you're
> suggesting, precisely.
> 
> a) Make it possible to nullify notifications under certain circumstances.
> b) Make it possible to ignore file owner/mode for files that exist already.
> 
> While (b) is rather tasteless to me (as is the whole "replace"
> parameter), it is certainly well in line of what's possible today, so I
> wouldn't object too much.
> (a) is a nightmare I hope you're not invested in.

Well, a in the service of b -- but as a general point, I think that every 
notify/subscribe should be tune-able as to which things changing will cause the 
action to take place.

>> I'm thinking of sites where you edit a policy and two seconds later
>> someone on a different team "kicks" the host for an entirely different
>> reason. And perhaps they should have used a tag to limit what they
>> kicked, but perhaps they forgot. Or perhaps their module depends on
>> yours so they so added your module as a tag.
> 
> This statement in itself is interesting as well. I believe that most
> sites, large or small, don't face this particular problem at all,
> because most of its incarnations are handled by manifest code control.
> If a change goes to production, it better work, otherwise whoever pushed
> to production has to answer for the breakage.

Exactly, which is why I said that the suggestions that someone edit the policy 
in advance and then send it out at the appropriate time make no sense at all.

> If you have a service that should under no circumstances be restarted
> unattended, then for crying out loud, do not make it consume resource
> notifications from puppet. That's begging for trouble.


That's not what I said. I said should not be restarted for any reason other 
than a change in the configuration file.

Not a change in the ownership for new sites.
Not a change in the mode for new sites.
etc...

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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] can we avoid notify/subscribe firing on a mode change?

[Jo Rhett]

On Jun 15, 2012, at 8:21 PM, Brian Gallew wrote:
> As has already been suggested, make the change yourself, submit a patch.  You 
> have indicated several times that this isn't that big a change.  Further, 
> it's a change that is clearly only of benefit to you at this point, so trying 
> to convince others to do it for you is pointless.  If you *really* want 
> Puppetlabs to do the change for you, then buy a support contract and have 
> them do it.


As with all open source projects, your suggestion above--although phrased 
nicely--is an eff off suggestion.  Submitting patches that people don't agree 
with is a waste of time.  That's why I poll in advance, rather than waste 
effort on something which won't get any attention paid to it.

It's obvious this is DOA, I'm just replying to the thread in hopes people 
realize the fallacy of illogical arguments. (not all are, but many have been so 
far)

-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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: 403 Forbidden with Passenger

[Michael Altfield]

jbrown,

Sorry for not posting my solution. I've been working on this install for 
weeks, and I *did* overcome this error, but I've had to overcome so many 
errors, I can't recall the exact fix. iirc, the solution might have been 
installing rubygem-rack through yum as opposed to gems.

In any case, here's the commands I have come up with to successfully 
install Puppet Master & puppet-dashboard on CentOS 6.2. (Note: this is 
incomplete: I'm still working on getting the Inventory Service up and 
running, and this install procedure still needs some hardening). FWIW:

# run this on just the Puppet Master, which should be running CentOS 6

# Generate Entropy for random-seed from Gold Image for Cert Generation

wget -O /var/lib/random-seed 
http://www.random.org/cgi-bin/randbyte?nbytes=200
# Configure DNS

echo "10.10.10.2 dashboard puppet" >> /etc/hosts

# skip this if DNS is setup properly
echo "10.10.10.3 puppetnode-01 puppetnode-01.mydomain.com" >> /etc/hosts
echo "10.10.10.4 puppetnode-02 puppetnode-02.mydomain.com" >> /etc/hosts
# …
# Add Repository - yum.puppetlabs.com

cat > /etc/yum.repos.d/puppetlabs.repo  /etc/puppet/puppet.conf << DELIM
[main]
logdir = /var/log/puppet
vardir = /var/lib/puppet
confdir = /etc/puppet
ssldir = /var/lib/puppet/ssl
rundir = /var/run/puppet
factpath = $vardir/lib/facter
templatedir = $confdir/templates

[master]
certname = 12345
dns_alt_names = puppet,dashboard,1234,12345
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY

reports = store, http
reporturl = http://12345:8080/reports/upload

[agent]
server = dashboard
report = true

[cert]
autosign = false

DELIM

# replace all instances of 12345 in puppet.conf with the FQDN
sed -e s,12345,`hostname`,g -i /etc/puppet/puppet.conf
# Puppet Master config.ru - Create

mkdir -p /usr/share/puppet/rack/puppetmasterd
mkdir /usr/share/puppet/rack/puppetmasterd/public
mkdir /usr/share/puppet/rack/puppetmasterd/tmp

cat > /usr/share/puppet/rack/puppetmasterd/config.ru < /etc/httpd/conf.d/puppet-master.conf << DELIM
## Puppetmaster Apache Vhost Configuration

# Update the paths of the next 2 lines to match your installed version of 
passenger
LoadModule passenger_module 
/usr/lib/ruby/gems/1.8/gems/passenger-3.0.13/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-3.0.13
PassengerRuby /usr/bin/ruby

## Passenger Limits
PassengerHighPerformance On
PassengerMaxPoolSize 12
PassengerPoolIdleTime 1500
PassengerMaxRequests 1000
PassengerStatThrottleRate 120
RackAutoDetect Off
RailsAutoDetect Off

Listen 8140


ServerName puppetmaster-01.mydomain.com

SSLEngine on
SSLCipherSuite SSLv2:-LOW:-EXPORT:RC4+RSA

SSLCertificateFile /var/lib/puppet/ssl/certs/12345.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/12345.pem
SSLCertificateChainFile /var/lib/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile /var/lib/puppet/ssl/ca/ca_crt.pem

## CRL checking should be enabled; if you have problems with
## Apache complaining about the CRL, disable the next line
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars

## The following client headers allow the same configuration
## to work with Pound.
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e

RackAutoDetect On

DocumentRoot /usr/share/puppet/rack/puppetmasterd/public


Options None
AllowOverride None
Order allow,deny
allow from all



DELIM

# replace all instances of 12345 in puppet-master.conf with the hostname
sed -e s,12345,`hostname`,g -i /etc/httpd/conf.d/puppet-master.conf
# Generate Puppet Master Certificates

# run this command to generate the puppet master certificates. Once you see 
the line:
# "notice: Signed certificate request for puppetmaster-01.mydomain.com"
# you should press ctrl+c to shutdown the WEBrick-powered puppet master 
process
# and proceed with the installation below

puppet master --verbose --no-daemonize --debug
# Start Puppet Master in Apache

service httpd start
# Install puppet-dashboard Dependencies

yum -y install

[Puppet Users] Re: Is this possible with Hiera - Puppet Module Development and using Hiera

[Steve Traylen]

On Monday, 18 June 2012 13:02:33 UTC+2, Peter wrote:
>
> Hi Puppet Users, 
>
> I have just started playing with Puppet and Hiera.  I am curious if it is 
> possible to control how hiera does variable lookup within a module I am 
> creating to test it.
>
>  
>
> I have read through the documentation I can find on Hiera and Puppet 
> however I cannot find any documentation suggesting a way to it.
>
>  
>
> For the record these are the versions that I am using (taken from the 
> Puppetlabs Debian/Devel):
>
> hiera (1.0.0-0.1rc3)
>
> hiera-puppet (1.0.0-0.1rc1-1-g3e68ff0)
>
> puppet-common (3.0.0-0.1rc3puppetlabs1)
>
> puppet (3.0.0-0.1rc3puppetlabs1)
>
>  
>
> Essentially I would like to define a hiera.yaml file (just the hierarchy 
> and puppet datasource location) within my module and use it to clearly 
> separate Operating System differences to the default state.  For example:
>
>  
>
The hiera.yaml file is the global configuration for all paths, however it 
could contain a 

path of 
/etc/puppet/modules/%{module_name}/config/operatingsystem
/etc/puppet/modules/%{module_name}/config/defaults


 

> -- {modulepath}/hiera.yaml ===--
>
> :hierarchy: 
>
>- %{operatingsystem}
>
> - defaults
>
>  
>
> :puppet:
>
>:datasource: %{modulename}/config/
>
> --===--
>
>  
>
> So in my module directory I could have:
>
> {modulepath}/config/debian.pp
>
> {modulepath}/config/centos.pp
>
> {modulepath}/config/defaults.pp
>
>  
>
> (It would be even better if in the file name somehow we could grip up 
> similar OS types, ie debian_ubuntu.pp)
>
>  
>
Look at the "osfamily" fact, this debian on ubuntu and redhat.
 

> I know that I can use puppet logic statements (case statements, if, …) to 
> set variables per OS but I feel that it would be cleaner and clearer to 
> separate the OS specific stuff and it would be easier to update a module 
> for a specific OS and override something set in the defaults.pp file.
>
>  
>
> So is this possible or is this something that could be considered as a 
> feature request.
>
>
So it's possible but you can't distribute the hiera.yaml with your module 
since this is a site setting.




 

>  
>
> Thanks,
>
>  
>
> Peter.
>

-- 
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/-/dlrUWu1b8OsJ.
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] Conditional with variable from facter

[Wolf Noble]

D'oh

On Jun 18, 2012, at 11:26 AM, Martin Alfke wrote:

> Hi,
>
> On 18.06.2012, at 17:14, Wolf Noble wrote:
>
>> Hi Jakov,
>>
>> the two semicolons locate these variables as  being in top-scope/variables 
>> outside of any specific module.
>
> please note that these are colons (:) no semicolons(;).

I will not respond to lists before coffee
I will not respond to lists before coffee
I will not respond to lists before coffee
...



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
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] Re: HTTP 400 errors when using storeconfigs

[Matthew Burgess]

On Thu, Jun 14, 2012 at 1:31 PM, Chris Price  wrote:
> Hi Matt,
>
> I think it would be worth opening a ticket for this
> ( http://projects.puppetlabs.com/projects/puppet/issues/new ).

Hi Chris,

This is now #15086. Hopefully there's enough info on the ticket to reproduce.

The VM is 1.5GB in size, so may be a little awkward to make available
to anyone working on the ticket, but I'm happy to give anything a try!

Regards,

Matt.

-- 
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] Re: Problem with Load Balancing Puppet masters with Apache mod_proxy

[kai]

Jeff, thank you very much for taking the time to answer all my questions. I 
really appreciate it. This thread had helped me a lot in my journey to 
mastering Puppet.
Thank you again!


-- 
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/-/4ZlSXYnIon8J.
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: 403 Forbidden with Passenger

[jbrown]

I'm having the same problem, but I never saw a solution in this thread. 
I've been over the permissions for config.ru and /var/lib/puppet about a 
1000 times and can't see any permissions problems.

-rw---. 1 puppet puppet 431 Jun 18 00:07 /etc/puppet/rack/config.ru
(I've also tried 700, 770, 777, and 660. I tried changing ownership to 
apache.apache, puppet.apache, and apache.puppet.)

$~ ll /var/lib/puppet/
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:21 bucket
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:09 facts
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:09 lib
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:21 reports
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:21 rrd
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:21 server_data
drwxrwx---. 8 puppet puppet 4096 Jun 18 00:09 ssl
drwxrwx---. 2 puppet puppet 4096 Jun 18 00:09 state
drwxrwx---. 4 puppet puppet 4096 Jun 18 01:12 yaml

Setenforce is 0.

I even went so far as to use "PassengerUser puppet" and "PaasengerGroup 
puppet" in my vhost, but that didn't help (and has been removed).

Could someone please help me?

Thanks,
Justin

On Wednesday, May 30, 2012 12:17:59 PM UTC-5, Michael Altfield wrote:
>
> Hello Puppet gurus,
>
> I'm trying to setup a Puppet environment on CentOS 6. I got it working 
> using WEBrick, but when I finally got Puppet running through Apache using 
> Passenger, my Puppet node gets this "403 Forbidden" response (full output 
> is attached as node.txt):
>
> [root@puppetnode-01 ~]# puppetd --waitforcert 30 --server 
>>> puppetmaster.mydomain.com --debug --verbose --test
>>
>> ...
>>
>> warning: peer certificate won't be verified in this SSL session
>>
>> err: Could not request certificate: Error 403 on SERVER: >> PUBLIC "-//IETF//DTD HTML 2.0//EN">
>>
>> 
>>
>> 403 Forbidden
>>
>> 
>>
>> Forbidden
>>
>> You don't have permission to access /production/certificate/ca
>>
>> on this server.
>>
>> 
>>
>> Apache/2.2.15 (CentOS) Server at puppetmaster.mydomain.com Port 
>>> 8140
>>
>> 
>>
>>
> At the same time, the httpd logs show this:
>
> [root@dx-puppetmaster-01 ~]# tail -f /var/log/httpd/*
>>
>> ...
>>
>> ==> /var/log/httpd/error_log <==
>>
>> [Wed May 30 12:46:21 2012] [error] [client 10.230.100.155] (13)Permission 
>>> denied: access to /production/certificate/ca denied
>>
>>
>>> ==> /var/log/httpd/access_log <==
>>
>> 10.230.100.155 - - [30/May/2012:12:46:21 -0400] "GET 
>>> /production/certificate/ca? HTTP/1.1" 403 325 "-" "-"
>>
>>
> The steps I used to install Puppet mostly followed the attached install.sh 
> script (with slight modifications). I've also tried to follow this 
> install 
> guide
>  to 
> no avail.
>
> Although I have not modified my /etc/httpd/conf/httpd.conf file, I've 
> attached it for reference. I've also attached 
> /etc/httpd/conf.d/passenger.conf and /usr/share/puppet/rack/puppetmasterd/
> config.ru. config.ru's perms are 600 puppet:root.
>
> Both of these machines are virtualized using Citrix XenServer. Here's some 
> more info on these boxes:
>
> [root@puppetmaster-01 ~]# cat /etc/redhat-release
> CentOS release 6.2 (Final)
>
> [root@puppetmaster-01 ~]# uname -a
> Linux puppetmaster-01.datalex.com 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed 
> Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> Any help will be greatly appreciated! :)
>

-- 
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/-/3A-FoU9nGokJ.
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] Conditional with variable from facter

[Martin Alfke]

Hi,


On 18.06.2012, at 17:14, Wolf Noble wrote:

> Hi Jakov,
> 
> the two semicolons locate these variables as  being in top-scope/variables 
> outside of any specific module.

please note that these are colons (:) no semicolons(;).

> 
> otherwise it might be $modulename::variable
> 
> Does that help at all?
> 
> W
> 
> On Jun 18, 2012, at 8:25 AM, Jakov Sosic wrote:
> 
>> Hi.
>> 
>> I have the following facts available:
>> 
>> # facter | grep oper
>> operatingsystem => CentOS
>> operatingsystemrelease => 6.2
>> 
>> Now, if I wish to use conditionals on these facts, I have to do it like
>> this:
>> 
>> case $operatingsystem {}
>> case $::operatingsystemrelease {}
>> 
>> 
>> I'm puzzled as to why can't I just use $operatingsystemrelease, and what
>> do these two semicolons mean?

You could use $::operatingsystem only. But you want to be sure that you also 
refer to CentOS.
I assume you want to net these two case conditionals:

case $::operatingsystem {
'CentOS': (
case $::operatingsystemrelease {
'5.0': {
...
}
'6.2': {
...
}
default: {
...
}
}
'Debian': {
...
}
default: {
...
}
}

Also take a look on the documentation:
http://docs.puppetlabs.com/guides/language_guide.html#conditionals

- Martin


-- 
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] PE Install Problem Finding /erb/console_auth_db_config.yml.erb

[hulk15]

Thanks Justin!  It appears that the extract was modified in some way. 

On Saturday, June 16, 2012 5:27:48 PM UTC-5, Justin Stoller wrote:

> On Fri, Jun 15, 2012 at 3:07 PM, hulk15 wrote: 
> > Hey guys, 
> > Trying to install PE for a PoC and have run into the following:  Has 
> > anyone seen this? 
> > 
> > Starting puppet:   [  OK  ] 
> > ** chkconfig pe-puppet on 
> > ** cp -a /etc/puppetlabs/puppet-dashboard/database.yml 
> > /etc/puppetlabs/puppet-dashboard/database.yml.20120615T215945.bak 
> > ** cp -a /etc/puppetlabs/puppet-dashboard/settings.yml 
> > /etc/puppetlabs/puppet-dashboard/settings.yml.20120615T215945.bak 
> > ** /opt/puppet/bin/erb -T - './erb/console_auth_db_config.yml.erb' > 
> > '/etc/puppetlabs/console-auth/database.yml' 
> > /opt/puppet/bin/erb:115:in `read': No such file or directory - 
> > ./erb/console_auth_db_config.yml.erb (Errno::ENOENT) 
> > from /opt/puppet/bin/erb:115:in `run' 
> > from /opt/puppet/bin/erb:140 
> > Thanks! 
>
> In the extracted tarball directory, the root install dir where 
> 'puppet-enterprise-installer' lives there should be a directory 'erb' 
> which contains the file 'console_auth_db_config.yml.erb'. Does this 
> exist? Have you done anything that could have removed either the file 
> or the directory? 
>
> The actual command is trying to load it from './erb/...' did you run 
> the installer from the directory where it resides (ie 
> './puppet-enterprise-installer') or from another location 
> '/tmp/extracted_dir/puppet-enterprise-installer'? 
>
> The file should be there unless the tarball/extracted directory was 
> tampered with and the installer should be able to find it as long as 
> it was ran from the directory where it sits. If the file doesn't exist 
> I'd try either re-extracting the tarball or re-downloading. If none of 
> that works, lemme know on the pe-users list (which is where questions 
> like this should go) which platform, major version, PE version, 
> tarball you've been getting and we can go from there. 
>
>
>  - Justin 
> > 
> > -- 
> > 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/-/yrKyyr-_yesJ. 
> > 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/-/dqQbKymSICIJ.
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] Conditional with variable from facter

[Wolf Noble]

Hi Jakov,

the two semicolons locate these variables as  being in top-scope/variables 
outside of any specific module.

otherwise it might be $modulename::variable

Does that help at all?

W

On Jun 18, 2012, at 8:25 AM, Jakov Sosic wrote:

> Hi.
>
> I have the following facts available:
>
> # facter | grep oper
> operatingsystem => CentOS
> operatingsystemrelease => 6.2
>
> Now, if I wish to use conditionals on these facts, I have to do it like
> this:
>
> case $operatingsystem {}
> case $::operatingsystemrelease {}
>
>
> I'm puzzled as to why can't I just use $operatingsystemrelease, and what
> do these two semicolons mean?
>
>
> Thank you.
>
> --
> 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.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
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] Re: Problem with Load Balancing Puppet masters with Apache mod_proxy

[Jeff McCune]

On Mon, Jun 18, 2012 at 7:06 AM, kai  wrote:

> I understand that only the CA cert needs to be copied on the LB and not
> the private key, as the private key is just for signing the agents
> certificates. Just wanted to note that the CA also needs
> SSLCARevocationFile, for revocation to work it seems.
> The only other concept that is not clear to me is why the CA keeps all the
> signed agents certs? Is there any need for that.
>

Puppet keeps the signed certificates as a record of what's been signed.
 The signed agent certificates are for informational purposes only and
aren't required to be kept around.

-Jeff

-- 
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] Service Puppetmaster being monitored by Nagios

[Wendell Araujo]

Good morning!

I have a server running Nagios and would like to monitor the service in my
puppet server puppetmaster. Has anyone managed to do this?

grateful

Wendell

-- 
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] Re: Problem with Load Balancing Puppet masters with Apache mod_proxy

[kai]

I understand that only the CA cert needs to be copied on the LB and not the 
private key, as the private key is just for signing the agents 
certificates. Just wanted to note that the CA also needs 
SSLCARevocationFile, for revocation to work it seems.
The only other concept that is not clear to me is why the CA keeps all the 
signed agents certs? Is there any need for that.


-- 
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/-/fchvaTsXZ7MJ.
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] Conditional with variable from facter

[Jakov Sosic]

Hi.

I have the following facts available:

# facter | grep oper
operatingsystem => CentOS
operatingsystemrelease => 6.2

Now, if I wish to use conditionals on these facts, I have to do it like
this:

case $operatingsystem {}
case $::operatingsystemrelease {}


I'm puzzled as to why can't I just use $operatingsystemrelease, and what
do these two semicolons mean?


Thank you.

-- 
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] Apparently service not restarted although is supposed to

[Javi]

Good morning.

Scenario: install SNMP (agent and daemon), change config file and restart 
of service.

What's wrong? The logs showed that AFTER the new config file is applied, 
the service (snmpd) is restarted, but looks like this is not true.

I arrived to this conclusion because if just after puppet finishes to load 
the catalog I run a snmpwalk command against localhost I get no response. 
After a restart of snmpd service, the new configuration applies.

Any error in below config?

Best regards

Client: test-3.dev.jj.com
Server: puppet-1.dev.jj.com

test-3.dev.jj.com:/var/log/daemon.log

Jun 15 17:07:27 test-3 puppet-agent[1219]: Reopening log files
Jun 15 17:07:27 test-3 puppet-agent[1219]: Starting Puppet client version 
2.6.2
Jun 15 17:07:48 test-3 puppet-agent[1219]: Caching catalog for 
test-3.dev.jj.com
Jun 15 17:07:48 test-3 puppet-agent[1219]: Applying configuration version 
'1339772181'
Jun 15 17:08:21 test-3 puppet-agent[1219]: 
(/Stage[main]/Apt::Service/Exec[/usr/bin/apt-get update]/returns) executed 
successfully
Jun 15 17:08:44 test-3 puppet-agent[1219]: 
(/Stage[main]/Snmp::Install/Package[snmp]/ensure) ensure changed 'purged' 
to 'present'
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: prNames
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: prNames
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: prErrMessage
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: prErrMessage
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: trigger OID: prErrorFlag
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown monitor OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: memErrorName
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: memErrorName
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: memSwapErrorMsg
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: memSwapErrorMsg
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: trigger OID: memSwapError
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown monitor OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: extNames
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: extNames
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: extOutput
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: extOutput
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: trigger OID: extResult
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown monitor OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: dskPath
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: dskPath
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: dskErrorMsg
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: dskErrorMsg
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: trigger OID: dskErrorFlag
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown monitor OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: laNames
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: laNames
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: payload OID: laErrMessage
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
unknown payload OID
Jun 15 17:09:01 test-3 snmpd[1877]: Unknown payload OID: laErrMessage
Jun 15 17:09:01 test-3 snmpd[1877]: /etc/snmp/snmpd.conf: line 143: Error: 
Unknown payloa

[Puppet Users] Re: Dashboard with RackbaseURI / and RailsAutoDetect off

[Chris Lee]

Has anyone ever got this right before?

-- 
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/-/DiGW9XkhIF4J.
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] Is this possible with Hiera - Puppet Module Development and using Hiera

[Peter J. Foley]

Hi Puppet Users,

I have just started playing with Puppet and Hiera.  I am curious if it is 
possible to control how hiera does variable lookup within a module I am 
creating to test it.

I have read through the documentation I can find on Hiera and Puppet however I 
cannot find any documentation suggesting a way to it.

For the record these are the versions that I am using (taken from the 
Puppetlabs Debian/Devel):
hiera (1.0.0-0.1rc3)
hiera-puppet (1.0.0-0.1rc1-1-g3e68ff0)
puppet-common (3.0.0-0.1rc3puppetlabs1)
puppet (3.0.0-0.1rc3puppetlabs1)

Essentially I would like to define a hiera.yaml file (just the hierarchy and 
puppet datasource location) within my module and use it to clearly separate 
Operating System differences to the default state.  For example:

-- {modulepath}/hiera.yaml ===--
:hierarchy:
   - %{operatingsystem}
- defaults

:puppet:
   :datasource: %{modulename}/config/
--===--

So in my module directory I could have:
{modulepath}/config/debian.pp
{modulepath}/config/centos.pp
{modulepath}/config/defaults.pp

(It would be even better if in the file name somehow we could grip up similar 
OS types, ie debian_ubuntu.pp)

I know that I can use puppet logic statements (case statements, if, ...) to set 
variables per OS but I feel that it would be cleaner and clearer to separate 
the OS specific stuff and it would be easier to update a module for a specific 
OS and override something set in the defaults.pp file.

So is this possible or is this something that could be considered as a feature 
request.

Thanks,

Peter.

-- 
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] arrays, notify, multiple config files, exec

[Felix Frank]

Hi,


> Am I close?

Yes, but some details are far out ;-)

On 06/16/2012 09:58 AM, Marc Lucke wrote:
> I think I an interate through the arrays using an inline_template in a
> define to run an exec using creates (to look for the .private file and
> generate it only if it doesn't exist).

I don't see how the template fits in here.

Structure:

opendkim_domain {
  "foo.org": subdomains => [ "foo", "bar", "baz" ];
}

define opendkim_domain($subdomains) {
  $domain = $name
  opendkim_subdomain { $subdomains: domain => $domain }
}

define opendkim_subdomain($domain) {
  $subdomain = $name
  # resources for creating stuff using values of $domain and $subdomain
}

You *can* unroll arrays to larger strings using inline templates, but
usually you only need defined types to process your data.

> I can notify if I create the
> private key or on KeyTable or on SigningTable, but I don't want to
> notify 3 times so the choice would seem to be to pick one.

This is a non-issue. 3 notifications are perfectly fine and will not
result in three restarts. Puppet will refresh your service resource at
most once per run.
The notify => metaparameter implies a "before" relationship, so puppet
also makes sure to evaluate all config pieces before the service
resource. So if any number of your configurations steps needs
performing, puppet guarantees (barring intermittent agent crashes) that
the service will be restarted as needed, but not more so.

HTH,
Felix

-- 
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] can we avoid notify/subscribe firing on a mode change?

[David Schmitt]

On 16.06.2012 02:21, Jo Rhett wrote:

On Jun 15, 2012, at 3:13 PM, jcbollinger wrote:

You seem to be interpreting many of the responses as assertions that
you shouldn't want what you're asking for. I don't think anyone is
saying that, at least not at the level of generality at which you
responded to David. On the other hand, several people, myself
included, have expressed valid concerns about the specific way you
suggest enabling your desired behavior. I cannot speak for the other
participants, but so far you have not addressed those concerns to my
satisfaction.


I just went back and re-read every complaint, and they can all be summed
up in

1. Too much complexity for too little gain (both of which are very
subjective)
2. You shouldn't use puppet for that.

The second one requires replacing puppet with a configuration management
system which can do the job, so it's an odd thing for everyone to
suggest. There hasn't been a single comment about the technical merits
of this change - even from yourself.


I say "running puppet *hot* on a system *when* restarting a service 
might create a booboo is a bad idea." Emphasis on *hot* and *when*. For 
both emphasises, there are solutions (noop, cron, schedules, 
mcollective, dssh). Using a different CM is not likely to solve that 
unless you're willing to go the build-freeze-scrap route.


The core of this runs into organizational realms like "Change 
Management", which are not in scope for the puppet master/agent. At the 
clients I work for, Rule #1 is "do not push into production." Even some 
of the outward-facing "test" systems have sensitive times when clients 
are testing. Developing changes and actually applying them are two VERY 
separate activities. You might want to look into git-flow to 
dis-entangle development, teams, and integration.


Do the cowboy-style sites have a quicker turn-over? You bet. Do they 
have the same uptime and stability requirements? Hell, no.


Best Regards, David

--
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] how to refresh ssh/authorized_keys file content ?

[David Schmitt]

On 16.06.2012 02:42, Jo Rhett wrote:

On Jun 15, 2012, at 8:19 AM, Nan Liu wrote:

To support purging, the puppet type need to to be able to query all
instances of the resource. In this case because ssh_authorized_keys
can write to different file locations, it does not have the ability to
detect all ssh keys that exists on the system and therefor it will not
have the ability to purge. In some cases, this is a limitation of the
provider which does not implement self.instances (for example this was
the case for a long time for mysql database type), but in this case I
don't believe it will ever support it.


Nan, this should be easy to do. Yes, there is a forest of authorized key
files on the host, for any given authorized_keys file you have a known
list of what keys should be there. I know for a fact it knows about the
other keys in the file, since it sometimes logs very weird error
messages about them if the key's comment matches another user's name.
http://projects.puppetlabs.com/issues/14809#change-64568

Since it reads in the authorized_keys file, and knows about the other
keys, it should be trivial to allow a purge=>true which removes any key
not defined in the manifest.


There's an issue for that:

http://projects.puppetlabs.com/issues/1581



Best Regards, David

--
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] cross server dependancies

[David Schmitt]

On 15.06.2012 21:19, Byron Appelt wrote:

I have an application package that needs to be installed on certain
application servers but before it can be installed, database access has
to be setup on a database server.

I have figured out how to export a resource on the app server that gets
collected and realized on the database server, but I cannot figure out
how to make the package on the app server depend on the exported
resource that gets realized on the database server.

I have tried something like this:

@@numerex_percona::database_grant{ $::mysql_hostname:
user => 'root',
password => $::mysql_server_root_password,
host => $::fqdn,
before => Package['ublipgw'],
}


But that doesn't work because Package['ublipgw'] is not on the server
where the database_grant is realized, but on the server where it is
exported. What is the best way to handle a situation like this?


Puppet doesn't support cross-node relationships. You'll have to manage 
that on a similar level as you are managing maintenance windows, that is 
by scheduling when changes to your manifests are actually applied to 
your nodes.


On a related note you need to make sure that the database_grant is able 
to manage its state without the other server being available, else you 
will run into troubles when you have transient problems with the other 
server or network later. In the simplest case a re-try might be 
sufficient, but, depending on your actual situation, might also be the 
worst thing that could happen.




Best Regards, David

--
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] can we avoid notify/subscribe firing on a mode change?

[Felix Frank]

Jo,

this thread is starting to confuse me, I am no longer sure what you're
suggesting, precisely.

a) Make it possible to nullify notifications under certain circumstances.
b) Make it possible to ignore file owner/mode for files that exist already.

While (b) is rather tasteless to me (as is the whole "replace"
parameter), it is certainly well in line of what's possible today, so I
wouldn't object too much.
(a) is a nightmare I hope you're not invested in.

> I find this whole discussion very interesting, in that it shows just how
> small of a team most puppet sites are.  I can't fathom modifying a
> template to push out a change, and being able to prevent that puppet
> client from picking up the change before the next maintenance window.
> It's just not possible in any reasonably sized site.
>
> I'm thinking of sites where you edit a policy and two seconds later
> someone on a different team "kicks" the host for an entirely different
> reason. And perhaps they should have used a tag to limit what they
> kicked, but perhaps they forgot. Or perhaps their module depends on
> yours so they so added your module as a tag.

This statement in itself is interesting as well. I believe that most
sites, large or small, don't face this particular problem at all,
because most of its incarnations are handled by manifest code control.
If a change goes to production, it better work, otherwise whoever pushed
to production has to answer for the breakage.

Of course, there may be sites that (for any number of reasons) cannot
adopt such a model(?)

On 06/15/2012 08:41 PM, Jo Rhett wrote:
> Not all things can be restarted after they are operating.  Some things
> need to be initialized restarted, and then never restarted again unless
> there is a good reason (like a configuration change). Saying "oh just
> restart it anyway makes no sense".  Why have refreshonly => true if that
> was so?

I don't mean to imply that we shouldn't have this whole discussion, but
the above example is hardly an argument in my humble optinion.

If you have a service that should under no circumstances be restarted
unattended, then for crying out loud, do not make it consume resource
notifications from puppet. That's begging for trouble.

Yeah, sorry for derailing this again ;-)

Best,
Felix

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