[Puppet Users] PuppetConf Call For Proposals Open!

[Nigel Kersten]

*The PuppetConf 2017 call for proposals is open*, and we'd love to have as
many community members as possible up on stage showing off your mad skills.

PuppetConf is in *San Francisco, California* this year, *10th to 12th of
October.*

The link to submit your talk proposal is here:
https://puppet.com/puppetconf/cfp-registration


We’re keen on all sorts of things, but particularly:

  * Stories and examples of DevOps success.
  * Real-world adventures involving technologies like cloud and containers,
innovative integrations with Puppet, or using Puppet to manage your
applications, infrastructure, and datacenter.
  * Introductory topics for getting started with Puppet; writing, testing,
and deploying modules; or your workflow and best practices recommendations.


If you're interested in presenting but would like some help developing your
idea into a great talk proposal, we'd love to help, and bouncing ideas off
other community folks is a good way to float ideas for a proposal.

Stop by the #speaking channel in the Puppet Community slack and we'll walk
through it together. (You can sign up at https://slack.puppet.com if you're
not already on it)

Puppet celebrates diversity. We've got travel scholarships for speakers
from underrepresented groups in tech who may not otherwise be able to
participate in PuppetConf. *To apply, indicate your interest on the talk
submission form.*

*Remember submissions need to be in by 23rd April - 19 days away...*

Thanks, and hope to see many of you in October whether you're speaking or
not!


cheers,

Nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAGUqgV83QFRaAUrz-8%2B1yGpw%3DcqZMSOPS55bCXqFjehVqiumPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 4 syntax highlighting in Wordpress

[Nigel Kersten]

I do Puppet syntax highlighting like this:

Open up puppet code in Vim with syntax highlighting on.

Use ":TOhtml" to save it as a formatted HTML file.

Either use the HTML snippet directly on a web page, or for some GUI HTML
editors, they'll understand styled text in your clipboard buffer (that's
how I preserve editable text, but syntax highlighted for PowerPoint/Keynote
slide decks)

This way I can toggle stuff like Vim line numbering that sometimes I want
on, and sometimes I want off, and I'm using the same syntax highlighter
that I use for normal editing of Puppet code.



On Sat, Apr 9, 2016 at 1:35 AM, Alex Harvey  wrote:

> I still haven't found any Puppet syntax highlighting plugins for Puppet (3
> or 4).  I'll be most grateful to anyone willing to share their secrets with
> me. :)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/247df98c-0a7c-4883-ae27-7580d5c2a808%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAGUqgV8abAnVfSzk5mH_nzMETxjo2APa-%2B7-V_HUTUL9o499bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PuppetConf 2015 Call For Proposals open

[Nigel Kersten]

TL;DR: go to http://puppetconf.com to find out details about PuppetConf and
submit a talk proposal, as submissions are now open.


This year PuppetConf is coming back to Portland, Oregon, and I'm really
excited to have the conference come back to the home of Puppet Labs HQ.

It's on Oct 5-9 this year, and I wanted to make sure the community knew
that the Call For Proposals is open, and we're really keen to get at least
as many great talks submitted as we had last year.


I'd specifically like to also call out that we're offering a limited number
of travel scholarships for accepted PuppetConf speakers who come from
underrepresented backgrounds and where financial support is a barrier to
their participation.

*** If you'd like to find out more about this program, even if you're
unsure whether or not you're going to submit a paper, please reach out to
me, as I'm more than happy to chat about it.  ***

That goes for any other topic around PuppetConf submissions too.


You can find all the details here:
https://puppet.wufoo.com/forms/mqsfhz81fk6gaz/ but here's a repost from
that page of the kinds of topics we're interested in:

- Introductory topics for getting started with Puppet, modules, and other
Puppet-related technologies (think OpenStack, AWS, VMware, DSC... and
whatever else you have Puppet working with).
- Using Puppet to solve problems around release management, continuous
delivery, application release automation, change control and more.
- Advanced tips and tricks for using Puppet, PuppetDB, Razor, Facter, etc.
- DevOps best practices around automation, culture, measurement and sharing.
- Cloud topics, including SaaS, PaaS, IaaS and hybrid deployments.
- Details of your learning journey, with a focus on what’s next for your
infrastructure. For example, what new automation technologies have you
experimented with, and what have you learned about using them in your
environment?
- Cool tools. Present on the tools you think the community should know more
about.
- Business topics like vendor selection hacks, managed service provider
(MSP) considerations, budgeting, etc.
- People-related topics around recruiting, management, team building,
career development and collaboration.
- Lessons learned from agents of change: how to overcome organizational
inertia, getting buy-in, the results of automation, what you have planned
next and what it will take to get there.


Submissions are due by midnight PDT on Sunday, May 17, 2015, and as
mentioned, I'm more than happy to chat about any questions you might have.



-- 
Nigel

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAGUqgV-fnW%2BEymdhwHAqEKk01buiHoLHOEAQ5MBRnuoGM4iUKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet 'node data' when using common node_names?

[Nigel Kersten]

On Wed, Aug 27, 2014 at 8:10 AM, jcbollinger john.bollin...@stjude.org
wrote:



 On Tuesday, August 26, 2014 6:24:57 PM UTC-5, Nigel Kersten wrote:




 On Tue, Aug 26, 2014 at 12:27 PM, Erik Dalén erik.gus...@gmail.com
 wrote:




 On 26 August 2014 20:22, jcbollinger john.bo...@stjude.org wrote:



 On Monday, August 25, 2014 11:13:40 AM UTC-5, Matt W wrote:

 Comments inline

 Matt Wise
 Sr. Systems Architect
 Nextdoor.com


 On Mon, Aug 25, 2014 at 6:55 AM, jcbollinger john.bo...@stjude.org
 wrote:






  Can you say a bit more about that?  What do you see that suggests
 agents are pulling down node information other than their catalogs (and
 later, any 'source'd files)?


 With nearly every puppet catalog compile, we also see GET requests
 like this:

 10.216.61.76 - XXX - puppet GET /production/node/xyz? HTTP/1.1 200
 13733 - - 0.021


 Where 10.216.61.76 is *not* the local IP of the puppet master... its
 the remote IP of the ELB, which indicates that its remote traffic from our
 puppet clients.



 That traffic might be coming from nodes, but all you know for sure is
 that it is traversing the ELB.  Surely the master could send requests
 through the ELB that end up coming back to it.  For all I know, the ELB
 might preferentially route such requests back to the originating host.

 From the perspective of the Puppet service lifecycle, the two most
 likely sources of such traffic are (1) an ENC retrieving node facts, and
 (2) the master determining nodes' environments.  I don't know any reason
 why nodes would be requesting their own node information, and even if they
 did, I can't see how that would affect the catalog the master serves to
 them.


 The reason for them to do this is to be able to use the environment that
 was configured on the master to fetch the plugins from. So first it tries
 to fetch its node info from the master to see if the environment in that is
 different than what it had configured locally. This is a new feature since
 puppet 3.0.

 In puppet 2.7 it used the fact plugins from the agent configured
 environment and the catalog from the master configured if I remember
 correctly.


 Yes, and also file resources came from the agent-configured environment
 even though the resource was from the master-configured environment, which
 resulted in much hilarity.




 I am well aware of all the old hilarity surrounding determining the
 environment from which to serve various bits, but I was unaware that the
 resolution involved agents requesting their environment from the master.
 That implies that the master *still* relies on the agent to correctly
 specify (echo back) the environment from which to serve those bits, else
 why would the agent need to know?

 If that's really what's happening then it's a poor design (which I guess
 is why I supposed it *wasn't* what was happening).  If the master is
 authoritative for a piece of information -- as it is for nodes'
 environments -- then it should not rely on relaying that information back
 to itself through an external actor -- that undermines its
 authoritativeness for the information.  Moreover, to the extent that the
 master does have such a reliance, it leaves Puppet open to malicious
 manipulation of the requested environment.

 So, um, are you sure?


Yes.  The bit of info we haven't mentioned is that if the client and server
environments don't match, and the server is set to be authoritative, then
it triggers the client to do a new pluginsync and run with the server
environment.

Tracking back to older tickets, there's a succinct description here from
Daniel Pittman:

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

(which has related tickets for the rest of the change)

The reason this was removed was to support the changes that made the ENC
authoritative over the agent environment. As part of that we had a
bootstrapping problem: the agent had an idea of the environment to request,
used that in pluginsync, and then as part of the request for the catalog.

If that idea was wrong, the catalog would be returned from the correct, ENC
specified environment, but it would have been generated with the wrong set
of plugins – including custom facts. So, the agent would detect that,
pluginsync to the new environment in the catalog, and compile a new catalog.

That fixed the problem, but was inefficient – every agent run with an
incorrect environment would mean two catalog compilations, and doubling
master load in a common situation (ENC says !production, agent run from
cron) was pretty unacceptable.

So, instead, the agent was changed to query the master for node data about
itself – and to use the environment that came back from that.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet

Re: [Puppet Users] Re: Puppet 'node data' when using common node_names?

[Nigel Kersten]

On Tue, Aug 26, 2014 at 12:27 PM, Erik Dalén erik.gustav.da...@gmail.com
wrote:




 On 26 August 2014 20:22, jcbollinger john.bollin...@stjude.org wrote:



 On Monday, August 25, 2014 11:13:40 AM UTC-5, Matt W wrote:

 Comments inline

 Matt Wise
 Sr. Systems Architect
 Nextdoor.com


 On Mon, Aug 25, 2014 at 6:55 AM, jcbollinger john.bo...@stjude.org
 wrote:



 On Saturday, August 23, 2014 12:46:59 PM UTC-5, Matt W wrote:

 Will,
   Thanks for the response. I know its a bit of a unique model -- but
 when you think about it, it makes a decent amount of sense. We run 
 hundreds
 of nodes that are fundamentally similar



 And therein is one of the key problems: similar, not identical.  If
 any node facts (including $hostname, $fqdn, etc.) vary among these hosts
 that are identifying themselves to the master as the *same machine*,
 then you are putting yourself at risk for problems.  Moreover, if security
 around your puppet catalogs is a concern for you, then be aware that
 positioning your node-type certificates as a shared resource makes it far
 more likely that they will be breached.  Additionally, you cannot limit
 which machines can get configuration from your master.


 To be very clear, we do not share certs across nodes. We absolutely use
 independent certs and sign them uniquely -- in fact, bug #7244
 https://projects.puppetlabs.com/issues/7244 was opened by me
 specifically for improving the security around SSL certs and auto signing.
 We make heavy use of dynamic CSR facts to securely sign our keys.

 More specifically, we've been waiting for the CSR attribute system to
 allow us to embed the puppet 'node type' (note, not identifier) in the SSL
 certs so that clients can't possibly retrieve a node type that isn't their
 own. (Bug #7243 https://projects.puppetlabs.com/issues/7243). It
 looks like this has been finally implemented, so we'll be looking into
 using it very soon (here
 https://docs.puppetlabs.com/puppet/latest/reference/ssl_attributes_extensions.html#extension-requests-permanent-certificate-data
 ).



 Lest it didn't catch your eye as it went by, I re-emphasize that Puppet
 is built around the idea that a machine's SSL certname is a unique machine
 identifier within the scope of your certificate authority.  What you are
 doing can work with Puppet, but you will run into issues such as the file
 naming effects you asked about.



 .. i.e. this is a web server, it gets the XYZ package installed and
 this is a web server, it gets the ABC package installed. Using hostnames
 to identify the systems node-definition makes very little sense and leaves
 quite a bit of room for error. Explicitly setting the node-type as a fact
 allows us to re-use the same node types but for many different 
 environments
 and keeps host-names out of the mix.



 Classifying based on a fact instead of based on host name is a fine
 idea, provided that you are willing to trust clients to give their type
 accurately to the server.  Having accepted that risk, however, you do not
 by any means need the node-type fact to be expressed to the master as the
 node's *identity*.  It could as easily be expressed via an ordinary
 fact.

 In particular, your site manifest does not need a separate node block
 for each node [identity], nor even to enumerate all the known node names.
 In fact, it doesn't need any node blocks at all if you are not going to
 classify based on node identity.  Even if you're using an ENC, it is
 possible for it to get the node facts to use for classification.


 Using a combination of both our nodes self-identifying themselves as
 well as the puppet node name architecture allows us to leverage the
 security of the 'auth' config file, while also having dynamically
 configured nodes where hostname doesn't matter.





 Realistically, hostnames are a terrible method for security ... someone
 could always break into a 'www' server and rename it to 'prod-db-thingy'
 and have it match the regex and subsequently get the database puppet
 manifest. (Just as a stupid simple example).



 No, they couldn't.  By default, Puppet relies on nodes' *certnames* to
 identify them.  That the agent uses hostname as certname by default is a
 convenient irrelevance once the master signs the node's certificate.
 Changing a node's hostname does not enable that node to get a different
 node's configuration, at least not under Puppet's ordinary configuration,
 because its certname does not change.  A node's certname cannot change
 without the CA's participation.



 For what its worth, our old model was a single 'default' node type and a
 simple fact ('base_class=my_web_server'). This worked extremely well, but
 left us more open to basically any client being able to request any catalog
 compilation. The auth-file in this world was effectively useless for
 preventing already-verified nodes from doing bad things.



 So you want to maintain information on the master that informs it what
 configuration(s) your nodes are 

Re: [Puppet Users] How to disable JIRA emails?

[Nigel Kersten]

On Sat, Aug 16, 2014 at 1:57 PM, Jos Backus j...@catnook.com wrote:

 Hi,

 I'm getting spammed incessantly by email from issue-upda...@puppetlabs.com
 to puppet-bugs, even though I'm not subscribed to the Google group
 puppet-bugs. How do I make it stop, please?


Hey Jos, it looks like you are actually subscribed but your account is in
the middle of a Google migration of some kind.

I'll sort it out for you off-list.

As a reminder to lurkers, you can always get in touch with the Google Group
owners off-list by either visiting:

https://groups.google.com/forum/#!aboutgroup/puppet-bugs

and hitting Contact Owner

If you prefer using email, the +owners suffix will always get you to the
list owners.

puppet-bugs+own...@googlegroups.com

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAGUqgV8bjyA1rqK6C3y5duC5229S7hQhxZ%2BBDW%3Dp2SWkoDPivg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Today's outage on tickets.puppetlabs.com

[Nigel Kersten]

We had an outage today on the Puppet Labs JIRA ticket tracker.

tickets.puppetlabs.com was unavailable from 1800 GMT to 2000 GMT (1110 PDT
to 1300 PDT)

The service is back up, and no data has been lost.

For anyone who is interested, we'll be publishing the results of our
post-mortem on the Puppet Labs blog this week.

If you have any immediate questions, please feel free to reach out to me
directly.


-- 
Nigel
CIO, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAGUqgV9CmB_vw5OHuJFY9tKko3AiO7V%3DZaKsoV_XuWicmdWHjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] New Puppet book: Extending Puppet

[Nigel Kersten]

On Thu, Jun 26, 2014 at 10:01 AM, Spencer Krum krum.spen...@gmail.com
wrote:

 Congratulations!
 On Jun 26, 2014 6:12 AM, Alessandro Franceschi a...@lab42.it wrote:

 Sorry for the shameless promotion, but I suppose this might be of
 interest for the readers of this group.


Congratulations Alessandro, I know you've been working on this for a while,
and great to see it out!



 After more that 6 months of pain, efforts, frustration and excitement
 it's finally out a book where I tried to pour all my knowledge and
 experience on Puppet.
 It's oriented to people who have already some experience on Puppet (for
 beginners there are definitively more fitting titles around) and I hope it
 can give some useful information also to experienced users.

 Find more about it at:
 http://www.packtpub.com/extending-puppet/book

 You can get a free chapter here: http://bit.ly/1qbxWZy

 I'd take this occasion to thank some members of this group for their
 support, in particular:
 Brice Figureau, who has been a great technical reviewer and has prevented
 me from making some big mistakes. His support and help has been decisive.
 Nigel Kersten, who has written the Foreword and has given me very useful
 hints and feedback.
 Joshua Hoblitt, who has reviewed some chapters and has given great
 advices on the language and the contents.
 Daniele Sluijters, who has been a very precise technical reviewer for
 some chapters.
 Jon Forrest, who has slashed the language of my first drafts and opened
 my eyes on what it means to write in proper english (I obviously haven't
 learnt how to do it properly, but thanks to the reviewers the final output
 has been definitively more linguistically appropriate than the first
 drafts).

 I hope this book can help people who work with Puppet and, if you happen
 to get it, please give feedback, in any way you find appropriate.

 Thank you
 Alessandro Franceschi

 --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to puppet-users+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/puppet-users/30744a77-5c0b-4a14-94ff-6fa4cd364b32%40googlegroups.com
 https://groups.google.com/d/msgid/puppet-users/30744a77-5c0b-4a14-94ff-6fa4cd364b32%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.

  --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to puppet-users+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/puppet-users/CADt6FWMaaAXZvu6vx0XLt%2Bvr4voFaYR7hR2AaeLJMHM8bnnzTg%40mail.gmail.com
 https://groups.google.com/d/msgid/puppet-users/CADt6FWMaaAXZvu6vx0XLt%2Bvr4voFaYR7hR2AaeLJMHM8bnnzTg%40mail.gmail.com?utm_medium=emailutm_source=footer
 .

 For more options, visit https://groups.google.com/d/optout.




-- 
Nigel

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAGUqgV8%3DgCMZ9Aa67uPy_RJXmbSJEkYAQSAjLWQrvO_YzGrRSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Welcome Cloudsmith to Puppet Labs!

[Nigel Kersten]

Some of you will already be familiar with Cloudsmith products such as
Geppetto, an IDE for Puppet modules, and some of you may be familiar with
the excellent work Cloudsmith folks like Henrik have done in areas like the
Puppet core parser.

We've been working together for a while now, and today we're thrilled to
announce the acquisition of Cloudsmith into the Puppet Labs family.


There is more about the acquisition on our blog:
https://puppetlabs.com/blog/cloudsmith-joins-puppet-labs/

For more info about the Puppet Module IDE Geppetto:


Geppetto: A Puppet IDE (blog)
http://bit.ly/12VlbCf

Geppetto 3.0 Overview (video)
http://bit.ly/12wsqR8

Geppetto, A Puppet IDE and Your Favorite Backseat Driver (podcast)
http://bit.ly/12Kz0SW



cheers,

Nigel Kersten

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Enterprise 3.0 now available!

[Nigel Kersten]

On Wed, Jun 26, 2013 at 9:41 AM, Nan Liu nan@gmail.com wrote:

 On Wed, Jun 26, 2013 at 1:33 AM, DEGREMONT Aurelien 
 aurelien.degrem...@cea.fr wrote:

 It is difficult to find what's inside Puppet Enterprise (which puppet
 version, etc...).
 I'm particularly interested to understand what was changed to have such
 gain in performances.


 I believe it's Puppet 3.2.2 and MC 2.2.4. Puppet 3 is overall
 significantly faster than Puppet 2.7:

 http://somethingsinistral.net/blog/the-angry-guide-to-puppet-3/#puppet-3-is-fast


Nan and David are both right. It's the Puppet 2.x - 3.x update, as well as
the use of PuppetDB for fact/catalog storage.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet Enterprise 3.0 now available!

[Nigel Kersten]

Hello puppet-users,

Puppet Enterprise 3.0 is now available now. You can download it now here:
http://puppetlabs.com/misc/pe-files/


This major release introduces the following new capabilities:

* Enhanced performance and scalability: 200% performance boost and 100%
increase in scalability helps you move faster and respond more quickly to
changing business needs
* New orchestration capabilities: Dynamically discover resources, then
fully orchestrate complex management operations on large volumes of cloud
nodes using Puppet Enterprise's orchestration engine.
* Software-defined infrastructure: Automate the management of not just
compute resources, but also network and storage resources, with Puppet
Enterprise's unified, software-defined approach

You can get a full overview of all of the new Puppet Enterprise
capabilities here:
https://puppetlabs.com/puppet/whats-new/

Or review the docs here:
https://docs.puppetlabs.com/pe/3.0/

I'm hosting live technical webinars and demo on Thursday, June 27.
Register today: https://puppetlabs.com/resources/webinars/

We hope you enjoy this release, and looking forward to your feedback!


Nigel Kersten
CTO, Puppet Labs
@nigelkersten

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: The free software tarballs are now difficult to find

[Nigel Kersten]

On Monday, October 15, 2012 10:39:07 AM UTC-7, windowsrefund wrote:

 This has nothing to do with being adept and also has nothing to do with 
 PL's business model. For a Free Software zealot such as myself, the 
 software and it's community is far more important. It was bad enough to see 
 the business agenda decide to switch to a non-copyleft license and now 
 we're seeing the free software version treated like a red headed 
 step-child. We've seen this trend play itself out hundreds of times over 
 the years and it's starting to look like PL is turning out to be a wolf in 
 sheep's clothing. We'll see...


We've hired and dedicated an experienced community manager for the 
community. 

In the last quarter we've released Puppet 3.0, PuppetDB 1.0, Hiera 1.0, and 
multiple MCollective releases, all great open source projects. 

Don't you think treated like a red headed step-child is rather hyperbolic?


-- 
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/-/9bTbPyS8Ds0J.
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: The free software tarballs are now difficult to find

[Nigel Kersten]

On Saturday, October 13, 2012 8:23:57 AM UTC-7, Paul Belanger wrote:

 On Friday, October 12, 2012 10:10:54 AM UTC-4, windowsrefund wrote:

 Recently, there have been some changes made to the Puppetlabs website 
 which result in the free software releases being difficult to locate and 
 download.

 Visitors using the download links are taken directly to the non-free 
 Enterprise option rather than being presented with an option.

 Personally, I'd like to see the site reverted so users have the option.

 FYI, the wiki section still provides this useful content here:

 http://projects.puppetlabs.com/projects/1/wiki/downloading_puppet

 Best,
 Adam Kosmin


 I was asking this on IRC the other day.  I understand the need to collect 
 information for prospective customers, however requiring a pay wall 
 (personal information) to access the open source tarballs does not seem to 
 be in the spirit of free software[1].


There are lots of ways people get open source Puppet, and not many people 
actually grab them in tarball form from the website from the stats we have.

Apart from being in the distributions, most of you seem to be getting 
software from the apt/yum repos, which don't require a paywall:

http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html

If you're hitting the main page, yes, the Download link goes to PE by 
default, with a link to the OSS download page at the bottom.

The Products - Puppet Open Source link on the main page takes you here:

http://puppetlabs.com/puppet/puppet-open-source/

where we promote getting the source from GitHub rather than tarballs 
directly from us.

The reasoning has generally been that if you want to use Puppet, the best 
way of consuming it is via packages, and if you want to get the source, the 
best way of consuming it is via Git.

That way updates are simpler for users, and development from source is 
simpler for developers.


-- 
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/-/vo711VUJ.
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] The Future of Puppet Dashboard

[Nigel Kersten]

(This mail has been sent to puppet-users, but bcc’d to puppet-dev and
puppet-announce to try and keep the conversation in one place.)


Summary:

* We are stopping investment in Dashboard
* Most Dashboard functionality will be replaced by two new open source
services
* Some Dashboard functionality will be replaced by a proprietary application
* The Dashboard will continue to be open source and we're happy to help
people take over maintenance
* If we don't get a new maintainer, we will announce a date to EOL Dashboard


Details:

If you’ve been following the development of Puppet Dashboard over the last
year or so, you’ve almost certainly noticed that it hasn’t been getting
much love from Puppet Labs.

We’ve been thinking about this for a while, and we’ve decided that we’re
not going to invest more in the Dashboard. It will get security patches and
some minor improvements over the next few months, but we’re treating it as
an evolutionary dead end.

We were planning to have some code ready for the replacement services
before making this announcement, but after questions at PuppetConf and
after the recent Dashboard update, we’ve realized that being transparent is
the right approach.

We’re generally moving the Puppet platform in a direction that is more
aligned with service-oriented-architecture, with standalone services for
specific functionality that own their own data.  Monolithic apps like the
Dashboard that store a variety of data types don’t fit well into this world.

You’ve seen the first moves of this with PuppetDB, where we have a
standalone, open source service with great APIs that is dedicated to
catalog and fact storage.

The ENC functionality in the Dashboard will be replaced by an open source,
standalone service.  The report storage and basic report viewing
functionality from Dashboard will become part of PuppetDB, and will be open
source, just as the rest of PuppetDB is. Work has recently started on both
of these projects. We will be working on data migration scripts from
Dashboard to these new services.

We will also be working on a new graphical application that provides an
interface to these services, but one more focused on workflows and advanced
use cases, and this application will be proprietary.

This is the model Puppet Labs is looking to follow from now on. Open source
services, with great APIs and simple GUIs just like PuppetDB, and
proprietary graphical applications that are more opinionated in terms of
workflows. We believe this is a simple line that brings a lot of clarity to
the difference between our open source and proprietary applications.

We’re still in the business of making Puppet a great open source platform,
and that’s not going to change. We will not be creating any secret APIs
that are just for use by Puppet Labs. We will be building our proprietary
apps on exactly the same APIs as everyone else has available to them.

We believe this keeps us honest in terms of keeping the open source
platform strong and functional, as well as Puppet Labs being fair and
equitable to the rest of the ecosystem compared to the applications we’re
building a sustainable company around.

We are not taking the Dashboard code base closed source.  Even though it’s
never really attracted a development community around it in the same way
that Puppet and MCollective have, if there are people who are committed to
its existence, we’re more than happy to help people take on the maintenance
role.

We do think that it ultimately will need to be completely rewritten to take
advantage of the new ENC and PuppetDB report storage, and it needs a
general update to a newer version of Rails, but just as with *any* other
open source application that builds upon our platform, we will help anyone
who wants to take this on.

We don’t have firm dates for when the replacement services will be ready,
but we expect their first releases to be out by the end of the year.  Once
both of these are ready, and we have migration scripts for your data, we’ll
announce a complete end of life date for Dashboard unless we have
replacement maintainers.

Again, if you love Dashboard enough to want to maintain it, this is your
chance.

I encourage and expect public discussion about this topic, but if you wish
to convey your thoughts privately, you can always contact myself or Luke at:


Nigel, CTO
email/jabber: ni...@puppetlabs.com
IRC : nigelk

Luke, CEO
email: l...@puppetlabs.com
phone: +1-615-594-8199.
IRC: lak


cheers,

Nigel Kersten

-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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] AW: Issue with large directory content

[Nigel Kersten]

On Thu, Sep 13, 2012 at 8:55 AM, Bernd Adamowicz
bernd.adamow...@esailors.de wrote:

 For me it still seems there's a kind of recursive scanning done by Puppet 
 though 'recurse' is set to false.

This does look like a bug, as you've got a directory with no remote
source, no recursion, and all you want to do is to enforce
owner/group/mode on it.

That shouldn't be an I/O intensive process at all.

-- 
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: newish puppet on RHEL4 and/or SLES9?

[Nigel Kersten]

About to unsubscribe this account as it was set to no email and looks
like a spam account.

On Wed, Aug 29, 2012 at 1:25 PM, Sam Kottler s...@kottlerdevelopment.com 
wrote:
 Who's got the ban hammer? :P


 On Wed, Aug 29, 2012 at 3:44 PM, shell Nor norenmich...@gmail.com wrote:

 My puppet has been created in isolation on an island at top of scotland
 over a period of 2 weeks nonstop working on her mismatched outfit.  sure
 youve probwho hsn't .  Flattery will get u know where..no.Know
 we're he're..wh'at i'd on't knowdumf...
 dumf   humfrey'yes
 m'lady.why do I love you so'.HumPhrey...
 YesM'lady.

 remember w is an upside down vivisection h is r 1 leaning again
 movemenf ..espanyolrythme and movemenf...
 what ya gonna do about the below  bell .ow...!!  stay team ent
 you wrote it its your scrip.crypt.whose hose hh
 .Mortgage coming to a show home near lend an ear...Job coming to a
 show you how Billed  the perfect invoice guaranteed to be
 presentable  F9,  Puppet, the honor you dont want to be
 without...Michele xX


 On Wednesday, August 15, 2012 3:41:32 PM UTC+1, Jason Antman wrote:

 I'm in the process of building out a new puppet master and pulling our
 existing/legacy infrastructure into Puppet control for the basic
 system-level stuff (mail, syslog, sudo, ssh, etc.). Unfortunately, the
 directive from on high is that all of our hosts need to be managed by
 the same system. That list is about 95% RHEL/Cent 5 or 6, but there's a
 few RHEL4 and SLES9 machines on the must have list. As upgrades are
 very unlikely, I'd like to be on the newest version possible - ideally,
 2.7.12+ on the master so I can leverage puppetDB.

 Is anyone out there running new-ish puppet (2.7, or else 2.6) on such
 ancient beasts? If so, can anyone point me at sources for the packages,
 and dependencies? Or perhaps have spec files to share?

 I'd like to say I can spend the time to build and test puppet and all
 the dependencies, but alas, that is very far from the case.

 Thanks for any assistance,
 Jason

 PS - If you happen to be a competent generalist Linux admin in the
 Boston, MA or Atlanta, GA area, feel free pass along your resume...

 --
 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/-/0DM356VV6JYJ.

 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.



-- 
Come to PuppetConf 2012! Sep 27/28 - San Francisco
http://puppetconf.com/

Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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] Best way to bail from facter script without using confine in Facter.add ?

[Nigel Kersten]

On Thu, Aug 23, 2012 at 7:17 AM, ZJE countac...@gmail.com wrote:

 On Wednesday, August 22, 2012 1:56:49 PM UTC-5, Nigel Kersten wrote:

 On Wed, Aug 22, 2012 at 11:13 AM, ZJE count...@gmail.com wrote:
  The slowdown comes from the command that I run before any Facter.add
  statements. It takes roughly 1.5 seconds to run and I would need to run
  it
  roughly 64 times if I had it in each Facter.add. Many facts are
  generated by
  a loop that contains a Facter.add, so I feel like some sort of exception
  would make things easier.  I'd like to avoid using a giant if
  statement if
  possible (there are roughly 100 lines of code that would be
  encapsulated).
  One of the main issues I have is that there are two different checks
  that
  happen in different parts of the code. I recognize that some may
  consider
  adding more if-statements as increased readability, but I feel like the
  added indentation for large chunks of code causes confusion for readers
  (especially when looking at loops).
 
  Thanks so much for your reply!

 You should be able to do something like this, which worked for the
 quick test I did, but I haven't extensively tested it.

 arr = [one, two, three, four]

 if true then
   # exit due to conditions for not running on this host
   exit
 else
   # run the command you'd run and store in an instance variable
 end

 arr.each do |e|
   Facter.add(tester_#{e}) do
 setcode do
   bleah
 end
   end
 end



 Hi Nigel,

 Thanks again for your reply. Currently, I'm using exit - but I think this
 causes the entire facter run to stop prematurely. If my script ends up being
 the first custom fact run, facter actually outputs nothing. Could there be a
 different problem?

 For example, if FACTERLIB=/opt/facter/facts and my custom fact looks like
 this:
 ---
 cat /opt/facter/facts/bailfact.rb
 #!/usr/bin/ruby
 Facter.debug In bailfact!
 exit
 ---

 I get:
 ---
 [root@testhost ~]# facter -d
 Relative directory ./facter removed from search path.
 Not an EC2 host
 in bail fact!
 ---

 and nothing else.

 If it helps, I'm using facter 2.0.0rc4

 Thanks!

heh. That makes sense :)

You're going to need to surround it all in a conditional then as far
as I can see.

-- 
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] Best way to bail from facter script without using confine in Facter.add ?

[Nigel Kersten]

On Wed, Aug 22, 2012 at 8:49 AM, ZJE countac...@gmail.com wrote:
 I have a script in $FACTERLIB that queries proprietary vendor tools for RAID
 configuration. These tools are quite slow, so the top of my .rb file calls
 the program once and stores the output in a variable. Multiple Facter.add
 statements then populate the facts. I would like to bail on this custom fact
 script if it's being run on a VM or unsupported host. I don't think
 confine would work here since I have multiple Facter.add and I would
 ideally like to bail before it gets to any of them. If I try exit, facter
 just exists and no other facts are collected. Looking at the code in
 facter/util/loader.rb, I could throw a ScriptError exception - but that
 seems hackish.

 Anyone have experience or suggestions for doing something similar? I've
 tried searching existing code with no luck.

You can surround the Facter.add calls with explicit checks like:

if Facter.value(:kernel) == Darwin
  Facter::Util::Macosx.hardware_overview.each do |fact, value|
Facter.add(sp_#{fact}) do
  confine :kernel = :darwin
  setcode do
value.to_s
  end
end
  end
end

(Yes, that confine there is somewhat redundant...)

Are you really seeing a significant slowdown though if you don't do
this and simply have the confine call within each Facter.add ? If so,
we should work on that.

-- 
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] Best way to bail from facter script without using confine in Facter.add ?

[Nigel Kersten]

On Wed, Aug 22, 2012 at 11:13 AM, ZJE countac...@gmail.com wrote:
 The slowdown comes from the command that I run before any Facter.add
 statements. It takes roughly 1.5 seconds to run and I would need to run it
 roughly 64 times if I had it in each Facter.add. Many facts are generated by
 a loop that contains a Facter.add, so I feel like some sort of exception
 would make things easier.  I'd like to avoid using a giant if statement if
 possible (there are roughly 100 lines of code that would be encapsulated).
 One of the main issues I have is that there are two different checks that
 happen in different parts of the code. I recognize that some may consider
 adding more if-statements as increased readability, but I feel like the
 added indentation for large chunks of code causes confusion for readers
 (especially when looking at loops).

 Thanks so much for your reply!

You should be able to do something like this, which worked for the
quick test I did, but I haven't extensively tested it.

arr = [one, two, three, four]

if true then
  # exit due to conditions for not running on this host
  exit
else
  # run the command you'd run and store in an instance variable
end

arr.each do |e|
  Facter.add(tester_#{e}) do
setcode do
  bleah
end
  end
end







 On Wednesday, August 22, 2012 11:36:13 AM UTC-5, Nigel Kersten wrote:

 On Wed, Aug 22, 2012 at 8:49 AM, ZJE count...@gmail.com wrote:
  I have a script in $FACTERLIB that queries proprietary vendor tools for
  RAID
  configuration. These tools are quite slow, so the top of my .rb file
  calls
  the program once and stores the output in a variable. Multiple
  Facter.add
  statements then populate the facts. I would like to bail on this custom
  fact
  script if it's being run on a VM or unsupported host. I don't think
  confine would work here since I have multiple Facter.add and I would
  ideally like to bail before it gets to any of them. If I try exit,
  facter
  just exists and no other facts are collected. Looking at the code in
  facter/util/loader.rb, I could throw a ScriptError exception - but that
  seems hackish.
 
  Anyone have experience or suggestions for doing something similar? I've
  tried searching existing code with no luck.

 You can surround the Facter.add calls with explicit checks like:

 if Facter.value(:kernel) == Darwin
   Facter::Util::Macosx.hardware_overview.each do |fact, value|
 Facter.add(sp_#{fact}) do
   confine :kernel = :darwin
   setcode do
 value.to_s
   end
 end
   end
 end

 (Yes, that confine there is somewhat redundant...)

 Are you really seeing a significant slowdown though if you don't do
 this and simply have the confine call within each Facter.add ? If so,
 we should work on 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/-/K5Mm3du3mkQJ.

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.



-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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] Dynamic Lookup of facter variable.

[Nigel Kersten]

On Mon, Aug 20, 2012 at 9:50 PM, Tim Mooney tim.moo...@ndsu.edu wrote:
 In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable.,
 Nigel...:

 Facts were supposed to be able to be referenced as $factname without
 throwing the deprecation warning in your release, it's been fixed in
 later versions.


 Are you saying that we do *not* need to reference facts as $::factname
 in all our classes, not even in preparation for puppet 3.x?  What if
 we *are* referencing them that way, now?


 There's no harm in going that extra mile and being explicit that
 you're looking at a top scope variable fact, rather than a local
 variable of the same name, so you can continue to reference them as
 $::factname if you would like to do so.

 Requiring that wasn't an original goal, as it was deemed too high a
 cost for the most common case to force that rather ugly syntax on
 everyone. It was a bug in the deprecation warning code.

 Does that help?


 It does help, thank you.

 It's one of those things that I wish I had known before I spent hours
 changing our modules in preparation for what I thought was going to
 be a requirement for puppet 3.x, but better late than never.  :-)

 I appreciate the clarity you've provided on this.

 Tim

I do apologize for us messing up the deprecation warning.

It's caused a lot of unnecessary churn for everyone, and it's
frustrating for everyone involved :(

-- 
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] Dynamic Lookup of facter variable.

[Nigel Kersten]

On Sun, Aug 19, 2012 at 8:00 PM, Douglas Garstang
doug.garst...@gmail.com wrote:
 Oh god that's ugly.

Yes it is, and it was an unwitting bug with the deprecation warning
that is resolved in later versions.

Facts were supposed to be able to be referenced as $factname without
throwing the deprecation warning in your release, it's been fixed in
later versions.



 On Sun, Aug 19, 2012 at 7:48 PM, Eric Shamow e...@puppetlabs.com wrote:
 Facts exist at top scope, as indicated in the scoping doc several people 
 have referred you to on this list.  Use $::ec2_instance_type

 Sent from my iPad

 On Aug 19, 2012, at 10:44 PM, Douglas Garstang doug.garst...@gmail.com 
 wrote:

 I don't get it...

if ! ( $ec2_instance_type in [$ec2_inst_type_allow]) {
notice(NOT ALLOWED)
} else {
notice(ALLOWED)
}

 2012-08-20T02:39:10.537134+00:00 truth puppet-master[24080]: Dynamic
 lookup of $ec2_instance_type at /truth/sauce/env/prod/modules/rol
 e/manifests/validate_server.pp:12 is deprecated.  Support will be
 removed in Puppet 2.8.  Use a fully-qualified variable name (e.g., $
 classname::variable) or parameterized classes.

 Line 12 is the if statement. However, on the same client system...

 [us1:i-16c5c050] root@testweb11:~# facter | grep ec2_instance_type
 ec2_instance_type = m1.large

 It's a facter variable. What's it complaining about?

 Doug.

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




 --
 Regards,

 Douglas Garstang
 http://www.linkedin.com/in/garstang
 Email: doug.garst...@gmail.com
 Cell: +1-805-340-5627

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




-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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] Dynamic Lookup of facter variable.

[Nigel Kersten]

On Mon, Aug 20, 2012 at 1:33 PM, Tim Mooney tim.moo...@ndsu.edu wrote:
 In regard to: Re: [Puppet Users] Dynamic Lookup of facter variable.,
 Nigel...:


 On Sun, Aug 19, 2012 at 8:00 PM, Douglas Garstang
 doug.garst...@gmail.com wrote:

 Oh god that's ugly.


 Yes it is, and it was an unwitting bug with the deprecation warning
 that is resolved in later versions.

 Facts were supposed to be able to be referenced as $factname without
 throwing the deprecation warning in your release, it's been fixed in
 later versions.


 Can you expound on this, Nigel?

 Are you saying that we do *not* need to reference facts as $::factname
 in all our classes, not even in preparation for puppet 3.x?  What if
 we *are* referencing them that way, now?

There's no harm in going that extra mile and being explicit that
you're looking at a top scope variable fact, rather than a local
variable of the same name, so you can continue to reference them as
$::factname if you would like to do so.

Requiring that wasn't an original goal, as it was deemed too high a
cost for the most common case to force that rather ugly syntax on
everyone. It was a bug in the deprecation warning code.

Does that help?

-- 
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] Running apt-get update on package install

[Nigel Kersten]

On Thu, Aug 9, 2012 at 2:00 PM, Denmat tu2bg...@gmail.com wrote:


 On 10/08/2012, at 3:20, Nigel Kersten ni...@puppetlabs.com wrote:

 On Thu, Aug 9, 2012 at 10:10 AM, Douglas Garstang
 doug.garst...@gmail.com wrote:
 I'm on Ubuntu, and I wanted to always have 'apt-get update' run before
 attempting to install packages, so I put this in my top level site.pp
 file:

 exec {
'refresh-repos':
command = '/usr/bin/apt-get update';
 }

 Package {
require = Exec['refresh-repos']
 }

 However, that causes a nasty cyclic dependency error. I really HATE
 those because the error message makes it impossible to interpret
 what's actually going on.

 How can I do this without the awful cyclic error messages?

 What version of Puppet are you on? Can you paste or link to the error
 message itself so we can actually tell what the dependency cycle is?

 I have used stages to handle this sort of thing. Setting up a repo stage to 
 refresh repos before the main stage.

 http://docs.puppetlabs.com/references/stable/metaparameter.html#stage

That's true, but stages aren't required to make this work.

It's impossible for us to tell why there is a dependency cycle here
without more info.

-- 
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] Running apt-get update on package install

[Nigel Kersten]

On Thu, Aug 9, 2012 at 10:10 AM, Douglas Garstang
doug.garst...@gmail.com wrote:
 I'm on Ubuntu, and I wanted to always have 'apt-get update' run before
 attempting to install packages, so I put this in my top level site.pp
 file:

 exec {
 'refresh-repos':
 command = '/usr/bin/apt-get update';
 }

 Package {
 require = Exec['refresh-repos']
 }

 However, that causes a nasty cyclic dependency error. I really HATE
 those because the error message makes it impossible to interpret
 what's actually going on.

 How can I do this without the awful cyclic error messages?

What version of Puppet are you on? Can you paste or link to the error
message itself so we can actually tell what the dependency cycle is?

-- 
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: can't authenticate based on IP? what? huh?

[Nigel Kersten]

On Fri, Jul 20, 2012 at 7:01 PM, Nick Lewis n...@puppetlabs.com wrote:
 On Tuesday, July 17, 2012 3:46:21 PM UTC-7, Jo wrote:

 Okay, I totally did see this in the release notes but I read it that you
 weren't allowing certificates with IP addresses in them, not that you
 wouldn't allow IP authentication in auth.conf at all.

 Jul 17 14:52:46 sj2-puppet puppet-master[13998]: Authentication based on
 IP address is deprecated; please use certname-based rules instead

 I don't feel that it is reasonable to expect that every puppet customer
 match up their naming scheme to their IP blocks, nor to want to list every
 possible naming scheme in their authorization list when an IP bitmask will
 do the job much more simply.

 I don't mind or care about IPs in certificates--I've never seen this, and
 don't expect to. But disallowing IP-based authentication is going to be very
 difficult at many sites, and possibly allow things which were never
 intended. Please reconsider this.


 This is actually something of a misleading deprecation warning, I'm afraid.
 The change we plan to make is to distinguish allow and allow_ip, to
 avoid confusing IPs and certnames. So the change you will need to make is to
 explicitly use allow_ip if you want to do IP-based authentication.
 However, adding that feature to 2.7.x, though backward compatible, turns out
 to require a fairly significant rework of some of the auth code, which is a
 risk we don't feel is appropriate. So the feature won't be in until 3, at
 which point it will be required.

 That means we're in the awkward position of issuing a warning you can't
 actually fix yet, which is *really* not something we like to do. But it
 seems better to at least give some alert that you'll need to make a change
 in the future than to have it suddenly occur without forewarning. So yes,
 there's definitely a bit of an issue here, but I assure you we don't intend
 to remove IP-based authentication entirely.

As Nick said, this wasn't something we took lightly, but I do believe
we've made the right interim decision.

Jo, can you provide a bit more detail about your specific use case so
we can be sure we're solving it going forward?

-- 
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: Can puppet manage an image rather than a running host

[Nigel Kersten]

On Thu, Jul 19, 2012 at 2:24 PM, jcbollinger john.bollin...@stjude.org wrote:


 On Thursday, July 19, 2012 3:14:04 PM UTC-5, bluckau wrote:

 Hi,

 Can puppet manage images (as opposed to running hosts)?

 This could be a chroot, an LXC container, etc.


 You could perhaps do this with a full-enough chroot environment, especially
 if you launch the agent on a single-run basis via an external scheduler
 (e.g. cron) instead of running it as a daemon.  You need to fool the agent
 into seeing the image as the actual operating environment.

I've done this in the past for producing images that are then used in
PXE setups so the gap between the image and Puppet stayed small.

We ended up needing to tread warily around things like Kerberos
principals, but it worked quite seamlessly so long as it looks like an
actual operating environment to Puppet.

-- 
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: How can I list classes available on the puppet master?

[Nigel Kersten]

Nan, I just assigned https://projects.puppetlabs.com/issues/7079 to
you, it would be awesome if you could let us know in that ticket if
your sample code suffers the same problem of classes with the same
name as a node masking the existence of that node.

On Thu, Jul 12, 2012 at 5:17 PM, Nan Liu n...@puppetlabs.com wrote:
 So this is turning it into a small coding contest =). I needed
 something similar to this, and there's a pretty easy way to do this
 with the puppet resource_type face.

 require 'puppet'
 require 'puppet/face'

 Puppet::Face[:resource_type,:current].search('*').find_all {|x|
 x.type==:hostclass}.collect{|x| x.name}.sort

 You can do some interesting things, such as get all the classes
 parameters as well:

 Puppet::Face[:resource_type,:current].search('*').find_all {|x|
 x.type==:hostclass}.collect{|x| {x.name=x.arguments.keys}}

 Here's an example of classes and parameters it accept:

 [{apt::backports=[release, location]},
  {apt::debian::testing=[]},
  {apt::debian::unstable=[]},
  {apt::params=[]},
  {apt::release=[release_id]},
  {apt::update=[]},
  {apt=
[purge_sources_list_d,
 purge_sources_list,
 always_apt_update,
 proxy_host,
 proxy_port,
 purge_preferences_d,
 disable_keys]},
 ...

 Thanks,

 Nan

 On Thu, Jul 12, 2012 at 9:50 AM, Nick Cammorato nick_cammor...@terc.edu 
 wrote:
 You could do something like this,  it's not the cleanest in the world(I
 barely ever use sed anymore), but as something quick and dirty:
 curl -k -H Accept: yaml https://puppet:8140/mgmt/resource_types/class |
 more | grep  name:  | sed -e 's/^ *name: //;s/id.* //' | sort | uniq

 It'll have some bad data you'll have to parse out(built-in classes like
 notify, fail, etc.), but should work.


 On Thursday, July 12, 2012 11:54:25 AM UTC-4, llo...@oreillyauto.com wrote:

 Is there a way to get a list of all the classes available from the puppet
 master?

 I have 2 goals for this - one is documentation in a human readable form,
 and the other is potentially importing that data into dashboard.

 I did find some info on the rest API
 (http://docs.puppetlabs.com/guides/rest_api.html#resource-types ) but I
 can't make any sense of the output from it.

 Thanks.

 Lee


 On Thursday, July 12, 2012 11:54:25 AM UTC-4, llo...@oreillyauto.com wrote:

 Is there a way to get a list of all the classes available from the puppet
 master?

 I have 2 goals for this - one is documentation in a human readable form,
 and the other is potentially importing that data into dashboard.

 I did find some info on the rest API
 (http://docs.puppetlabs.com/guides/rest_api.html#resource-types ) but I
 can't make any sense of the output from it.

 Thanks.

 Lee


 On Thursday, July 12, 2012 11:54:25 AM UTC-4, llo...@oreillyauto.com wrote:

 Is there a way to get a list of all the classes available from the puppet
 master?

 I have 2 goals for this - one is documentation in a human readable form,
 and the other is potentially importing that data into dashboard.

 I did find some info on the rest API
 (http://docs.puppetlabs.com/guides/rest_api.html#resource-types ) but I
 can't make any sense of the output from it.

 Thanks.

 Lee


 On Thursday, July 12, 2012 11:54:25 AM UTC-4, llo...@oreillyauto.com wrote:

 Is there a way to get a list of all the classes available from the puppet
 master?

 I have 2 goals for this - one is documentation in a human readable form,
 and the other is potentially importing that data into dashboard.

 I did find some info on the rest API
 (http://docs.puppetlabs.com/guides/rest_api.html#resource-types ) but I
 can't make any sense of the output from it.

 Thanks.

 Lee

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

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.

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




-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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 can I list classes available on the puppet master?

[Nigel Kersten]

On Thu, Jul 12, 2012 at 8:54 AM, llow...@oreillyauto.com
llow...@oreillyauto.com wrote:
 Is there a way to get a list of all the classes available from the puppet
 master?

We've actually addressed this more directly in the upcoming Telly
branch, where we've extended the resource_type REST API to make this
simpler:

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

You'll be able to directly ask the question via an API of what
classes exist in this environment?

Note you can do this already prior to Telly, but you need to do
filtering yourself on the returned output to just grab class
information.





 I have 2 goals for this - one is documentation in a human readable form, and
 the other is potentially importing that data into dashboard.

 I did find some info on the rest API
 (http://docs.puppetlabs.com/guides/rest_api.html#resource-types ) but I
 can't make any sense of the output from it.

 Thanks.

 Lee

 --
 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/-/wmJFsgZDA8sJ.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.



-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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] Ruby custom fact question/problem

[Nigel Kersten]

On Fri, Jun 29, 2012 at 1:05 PM, llow...@oreillyauto.com
llow...@oreillyauto.com wrote:
 I originally started this post to ask about one problem, but in the process
 of getting the question written I learned that it was due to differences
 between 1.8.7 and 1.9.2 that had caused my problem, so I got that fixed.

 I now have the fact successfully loading when I run puppet:

 info: Loading facts in /var/lib/puppet/lib/facter/node_id.rb

 However, when I run facter, I can't find node_id.

 facter | grep node
 No LSB modules are available.

You need to tell Facter to load the puppet facts like:

facter -p | grep node

or just

facter -p node_id




 Is there another step I am missing? Also, one thing I didn't understand (and
 so may have done wrong) is how the actual fact gets set. Is it simply the
 last variable/string used in the code?

Yep.



 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/-/nRd4lsLLKd0J.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.



-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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] Fwd: possible changes to puppet config file

[Nigel Kersten]

On Thu, Jun 28, 2012 at 1:40 AM, David Schmitt da...@dasz.at wrote:

 If you're at it: It is ugly that an environment master will automatically
 pull in the puppetmaster settings too. Especially if the manifests are in
 git and every branch is an environment.

Are you saying that you're defining an environment with the name
master David ?

Are you doing this in a block like: [master] or by using
$environment in the modulepath/manifest directives ?


-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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/Hiera and Git workflow

[Nigel Kersten]

On Mon, May 28, 2012 at 6:14 AM, Andy Taylor andytaylo...@gmail.com wrote:

 I'm currently trying to work out the best way structure my Puppet
 environments and VCS structure. At the moment I'mk working on
 something like this:

 Three Git repositories (one for modules, one for Hiera, one for node
 manifests)
 Multiple branches (each branch representing an environment, e.g.
 production, dev, testing etc.)

 When changes to modules/Hiera are made, the changes will be made to a
 testing branch, and then merged up the branches until it hits
 production (with the appropriate testing of course). So something like
 this:

 unstable  dev  testing  production


Do you need a distinction between unstable and dev ? I've often found
that I don't need those to be separate stages.





 What system do you guys use? Any suggestions about the above workflow?

 Thanks!

 Andy

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




-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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 / scalability

[Nigel Kersten]

On Sun, May 13, 2012 at 11:53 PM, Alex Harvey alexharv...@gmail.com wrote:

 Hi list,

 I am looking at configuration management tool options.

 I have a large fleet ( 3,000 hosts) and highly heterogeneous
 (RHEL3-5, CentOS, 5RH7, Solaris 10 LDOMs/zones, Solaris 8-9, AIX 5.3 
 6.1 LPARs, HP-UX  Tru64 + Windows).  We care mainly about RHEL and
 new versions of Solaris  AIX but ability to compile on older versions
 is an advantage.  Probably, the Windows will be managed by SCCM.

 I have read that Puppet could have scalability problems to a site as
 large as ours.  To keep this simple, I'd like feedback on whether that
 is likely to be true for us.

 A rep from CFengine has told me that ours would be the largest Puppet
 site in the world (I think that's not true).  Could someone confirm?


There are at least a couple of deployments that are more like 30k hosts
than 3k

It's absolutely not true.




 General feedback also welcome.

 Kind regards,
 Alex Harvey

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




-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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: ANNOUNCE: Puppet Module Tool version 0.3.4

[Nigel Kersten]

On Thu, May 10, 2012 at 8:27 PM, Matt mjbl...@gmail.com wrote:

 Reading the documentation so far, it looks like it has the option to query
 a different repository other than forge. The question I have is if we have
 modules that we need to host internally how can we serve them up to be
 searchable by PMT?


This isn't really something we've made easy for you yet Matt, but we are
definitely working in this area.

We want to stabilize the Forge APIs so that we can publish them and make a
public API we support so people can have services that operate as a module
repository.

We're also looking at making it so that you can reference git URIs for
modules, which is probably a simpler option for many people and a more
natural workflow fit.

Where was the documentation that you ran across Matt? It looks like we've
leaked out something we were using for internal development when testing
changes to the Forge itself.






 On Tuesday, August 9, 2011 6:47:59 PM UTC-4, James Turnbull wrote:

 Hi all

 We've just released version 0.3.4 of the puppet-module tool used to
 create and retrieve modules from the Puppet Labs Forge
 (http://forge.puppetlabs.com).

 You can update using Ruby gems:

 $ gem install puppet-module

 There are several important changes in this release:

 * Add ability to install modules with hyphens
 * Add check for symlink when installing
 * Install modules to their name not full name
 * Add semantic version support

 The major functional difference is in how modules are installed, for
 example a module named:

 jamtur01-apache

 Will now be installed into your module path as:

 apache

 You can find the code and full commit logs at:

 https://github.com/puppetlabs/**puppet-module-toolhttps://github.com/puppetlabs/puppet-module-tool

 Regards

 James Turnbull

  --
 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/-/nMXLUbPYvfgJ.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten
Schedule Meetings at: http://tungle.me/nigelkersten

-- 
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 3.0 and Hiera

[Nigel Kersten]

On Mon, May 7, 2012 at 7:22 AM, Derek J. Balling dr...@megacity.org wrote:


 On May 3, 2012, at 1:05 PM, Pieter van de Bruggen wrote:

 As many of you may be aware, Hiera will be tightly integrated into Puppet
 in the upcoming release of Puppet 3.0.

 What will this mean for sites that have specifically avoided using Hiera?
 I would presume that this should just mean business as usual, with no
 significant impact?


Yes. If you're not planning to externalize data at all, the only difference
you'll see is that you'll now have Hiera installed on your system when you
install Puppet 3.0.

-- 
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 3.0 and Hiera

[Nigel Kersten]

On Mon, May 7, 2012 at 9:26 AM, Derek J. Balling dr...@megacity.org wrote:


 On May 7, 2012, at 11:54 AM, Nigel Kersten wrote:
  Yes. If you're not planning to externalize data at all, the only
 difference you'll see is that you'll now have Hiera installed on your
 system when you install Puppet 3.0.

 Cool. Was really panicking there for a moment.

 I kinda like having human readable manifests as opposed to machine
 readable YAML  :-)


Externalizing data actually helps things be much more human readable imho,
as you end up having semantically useful labels in the puppet manifests
rather than naked data.

But yes, if you're not interested in externalizing data, so you haven't put
anything in the Hiera store, and continue to embed data in your manifests,
everything will still work as before.




-- 
Nigel Kersten | http://puppetlabs.com | @nigelkersten

-- 
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 3.0 and Hiera

[Nigel Kersten]

On Sat, May 5, 2012 at 9:26 AM, Trevor Vaughan tvaug...@onyxpoint.comwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 With the integration of Hiera, is the extlookup functionality being
 deprecated?

 If so, I would like to ask that the team add a Hiera backend for the
 existing extlookup data sources.

 I know that it won't support hashes but it would help to break the view
 that Puppet routinely breaks existing functionality on upgrades.


We'll deprecate it, but not *break* it.

We'd go through a whole release cycle before actually removing the
extlookup function, and as RI pointed out, we can migrate the backend
stores from extlookup CSV to straight up JSON/YAML.

-- 
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] Using fact to determine node environment

[Nigel Kersten]

On Wed, May 2, 2012 at 4:19 AM, R.I.Pienaar r...@devco.net wrote:



 - Original Message -
  From: John Kennedy skeb...@gmail.com
  To: puppet-users@googlegroups.com
  Sent: Wednesday, May 2, 2012 11:59:49 AM
  Subject: [Puppet Users] Using fact to determine node environment
 
  We have a custom fact that we wrote to determine which (business)
  environment a specific server belongs to (test, stage, production).
  We want to set up puppet environments (again, test, stage, and
  production).
  Is it possible to use our custom fact to set which environment a node
  belongs to?

 your only option at present is to write out puppet.conf using a template
 with your fact


Unless something broke it recently, I ran for years with a fact that
returned :environment and didn't set it in puppet.conf at all.

-- 
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] Using fact to determine node environment

[Nigel Kersten]

On Wed, May 2, 2012 at 8:18 AM, R.I.Pienaar r...@devco.net wrote:



 - Original Message -
  From: Nigel Kersten ni...@puppetlabs.com
  To: puppet-users@googlegroups.com
  Sent: Wednesday, May 2, 2012 4:10:16 PM
  Subject: Re: [Puppet Users] Using fact to determine node environment
 
 
 
 
  On Wed, May 2, 2012 at 4:19 AM, R.I.Pienaar  r...@devco.net  wrote:
 
 
 
 
 
  - Original Message -
   From: John Kennedy  skeb...@gmail.com 
   To: puppet-users@googlegroups.com
   Sent: Wednesday, May 2, 2012 11:59:49 AM
   Subject: [Puppet Users] Using fact to determine node environment
  
   We have a custom fact that we wrote to determine which (business)
   environment a specific server belongs to (test, stage, production).
   We want to set up puppet environments (again, test, stage, and
   production).
   Is it possible to use our custom fact to set which environment a
   node
   belongs to?
 
  your only option at present is to write out puppet.conf using a
  template
  with your fact
 
 
 
 
  Unless something broke it recently, I ran for years with a fact that
  returned :environment and didn't set it in puppet.conf at all.

 yes, it broke.  You'll get a mix of files from one environment and classes
 from another etc, puppet.conf is the only option now


I think you're thinking of the ENC setting the environment, not a fact
called 'environment' RI?

-- 
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] Using fact to determine node environment

[Nigel Kersten]

On Wed, May 2, 2012 at 8:37 AM, R.I.Pienaar r...@devco.net wrote:


   Unless something broke it recently, I ran for years with a fact
   that
   returned :environment and didn't set it in puppet.conf at all.
 
  yes, it broke. You'll get a mix of files from one environment and
  classes
  from another etc, puppet.conf is the only option now
 
 
 
 
  I think you're thinking of the ENC setting the environment, not a
  fact called 'environment' RI?

 nope.


Anyone got a bug # for this?

-- 
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] Using fact to determine node environment

[Nigel Kersten]

On Wed, May 2, 2012 at 8:53 AM, R.I.Pienaar r...@devco.net wrote:


I think you're thinking of the ENC setting the environment, not a
fact called 'environment' RI?
  
   nope.
  
  
   Anyone got a bug # for this?
 
  pretty sure there was one but couldnt find it so I just knocked up a
  quick test, this has been discussed to death in the past

 should say I am on 2.6.x here, this may well have been fixed in 2.7.x


That's the puzzling bit. It was definitely working for me in production in
earlier 2.6.x days.

I just tested with 2.7.x and it's broken too.

I'll go hunting through the bug tracker today and update the bug or file a
new one.

Frustrating.

-- 
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] What is the false directory?

[Nigel Kersten]

This should get reported as a bug though.

We should probably only accept absolute paths for the 'path' parameter, and
false should get interpreted as the boolean.

On Tue, Apr 24, 2012 at 6:38 AM, Peter Bukowinski pmb...@gmail.com wrote:

 Glad you got it sorted. You've discovered the importance of quoting and
 *not* quoting. The best practice is to single quote any string that does
 not contain a variable. If you're using a variable, use double quotes so it
 gets interpreted properly. Quotes should *not* be used around any of
 puppet's native values, e.g. true/running, false/stopped, present, absent,
 file, directory, link latest, absent, purged, etc.

 --
 Peter

 On Apr 24, 2012, at 9:21 AM, Sans wrote:

 Thanks Peter! Got it now!

 You were absolutely right - I had *path   = 'false' *for filebucket (in
 the site.pp).
 But I thought, Puppet recommends to quote around everything (apart from
 variables). That's not true, I see. Cheers!!



 On Tuesday, April 24, 2012 2:12:02 PM UTC+1, Sans wrote:

 I don't know what exactly you mean: I don't have any path defined with
 false in it.
 Just figured out that whenever the content of a file is being modified,
 the *false* directory is being created with the old file (as
 content) in it. So, looks like it's actually not modifying the file (in
 question) at all but replacing with the new one and keeping the old (i.e.
 original) one in the *false* directory. Am I making any sense here at
 all? Cheers!!




 On Tuesday, April 24, 2012 1:39:16 PM UTC+1, pmbuko wrote:

 Looks like you have an error in your filebucket definition. Did you,
 perhaps, put quotes around false when you defined the path?

 -- Peter

 On Apr 24, 2012, at 8:13 AM, Sans r.santanu@gmail.com wrote:

 Dear all,

 Since last night, Puppet is started creating a directory, named *false*in 
 the present working directory, if I run
 *puppetd -t* manually on the puppet agent. The directory contents are
 like this:

 8/3/e/5/8/6/5/9/**83e586594432759eb7aed007e888a1**72/contents
 8/3/e/5/8/6/5/9/**83e586594432759eb7aed007e888a1**72/path



 does any one know what are these and why they are being created?
 Cheers!!

 --
 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/-/**nKerekDGmcoJhttps://groups.google.com/d/msg/puppet-users/-/nKerekDGmcoJ
 .
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to puppet-users+unsubscribe@*
 *googlegroups.com puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at http://groups.google.com/**
 group/puppet-users?hl=enhttp://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/-/M9LXUDvJXtYJ.
 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.


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


-- 
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] Migrate installation to different directory

[Nigel Kersten]

On Tue, Apr 24, 2012 at 11:18 AM, JA atkins.jac...@gmail.com wrote:

 Stefan;

 Thanks for the suggestion.  However, we are running puppet via
 Passenger.  So, I assume I need to update the config.ru file.  Do you
 have any suggestions about that?  Greatly appreciate your help and
 advice!


Look for the ARGV line like:

ARGV  --rack

and modify it to:

ARGV  --config  path/to/your/config  --rack





 On Thu, Apr 19, 2012 at 6:17 PM, Stefan Schulte
 stefan.schu...@taunusstein.net wrote:
  On Thu, Apr 19, 2012 at 03:56:37PM -0400, JA wrote:
  Hi Everyone;
 
  I want puppet to be installed in /app/puppet instead of the default
 /etc.
  I cannot figure out how to get the puppetmasterd to look for the
  config file (puppet.conf) in /app/puppet instead of /etc/puppet.
 
  If anyone can help, I would really appreciate it!
 
 
  It should work if you start your master with --confdir /app/puppet
 
  -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.
 

 --
 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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

[Nigel Kersten]

On Tue, Apr 17, 2012 at 10:34 AM, Tim Mooney tim.moo...@ndsu.edu wrote:

 In regard to: Re: [Puppet-dev] Re: [Puppet Users] Telly: Nagios types...:


  Todd, welcome and I feel your pain.  Trust me, I pushed every way I
 could to use native packages as our module deliver mechanism.  However
 we have some odd requirements that make things not work as well with
 RPM (or deb, or gems).  Basically we need a mechanism to allow
 multiple versions installed into separate environments (paths on
 disk).


 You make a compelling argument for why this doesn't map well to native
 packaging tools.  While it is possible to have multiple copies of an RPM
 installed simultaneously, it would be a kludge in this case.


  Something like pm2rpm and pm2deb is very likely something we'll need
 to make the lives of Puppet Users happy.


 Now that puppet has drug me into the ruby world, I've started down the
 path of RPM packaging of gems.  gem2rpm helped me get started.  Having
 something that works very similar to that would be a big help to those
 that are experienced with ruby  gems.

 Whatever you choose, though, there needs to be a way for admins to query
 a client and find out

- what puppet modules are installed
- where each instance of the module is installed
- what version is present in each instance


Absolutely. This is the functionality we'll have available in Puppet.

# puppet module list
/etc/puppetlabs/puppet/production/modules
└── nigelkersten-testmac (v0.0.2)
/opt/puppet/share/puppet/modules
├── puppetlabs-pe_accounts (v1.0.2)
├── puppetlabs-pe_compliance (v0.0.6)
├── puppetlabs-pe_mcollective (v0.0.43)
└── puppetlabs-stdlib (v2.3.1)

-- 
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] Determining if hiera (or any function) is installed on a node

[Nigel Kersten]

On Tue, Apr 17, 2012 at 11:08 AM, Geoff Davis gada...@ucsd.edu wrote:

 I'm doing some work on module development inside of a Vagrant VM of CentOS
 6.2. This VM has the community version of Puppet installed (2.7.13 I
 think), but that doesn't include Hiera by default.

 My module is dependent on Nan Liu's puppet-staging module, which requires
 hiera. This puts me into the proverbial chicken and egg problem of not
 having a puppet function but also not being able to install it with puppet,
 since my manifests don't compile due to the hiera function not being
 available.

 Right now, I'm doing a manual bootstrap of a new vagrant box with a
 dedicated Puppet manifest that calls another one of Nan's modules,
 puppet-hiera, to install hiera on the Vagrant VM, but I'd rather use the
 same manifest for both bootstrap and module testing. I don't care if it
 takes two passes to converge, I just don't want a freshly booted Vagrant
 box to complain because it can't compile it's manifest.

 Is there a relatively foolproof way to determine if Puppet has a function
 available to it or not? Is there a has_function function available in the
 Puppet DSL, or is there a check that I could roll into a fact that works
 cross-platform and between Puppet Enterprise and Community?


There's a pending pull request in the stdlib module for adding a
function_available function

https://github.com/puppetlabs/puppetlabs-stdlib/pull/59

-- 
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-dev] Re: [Puppet Users] Telly: Nagios types moving into Module

[Nigel Kersten]

On Mon, Apr 16, 2012 at 11:36 AM, Todd Zullinger t...@pobox.com wrote:

 Michael Stahnke wrote:

 For the next major Puppet version, code-named Telly, we have some changes
 coming.  This is the first in a series of emails around these changes and
 may require some input from the community.

 For Telly, the nagios types will be moved into a module.  This allows
 them to be iterated on in isolation from the rest of Puppet's core release
 cycle and process. In the future we have plans to move several other types
 into modules that can be individually maintained, improved, tested and used.

 The module for Nagios will be available on the Forge.

 The upgrade path is the thing we need some feedback about.  The basic
 steps to upgrade would be to setup a Telly master, and then install the
 Nagios module via the Puppet Module Tool, which ships integrated with
 2.7.13+ and Telly.


 Is it possible to package these modules for distros?  In the past, we've
 had a few requests to do this for third-party modules but we didn't do this
 because there wasn't really any standard for it.  With puppet module tool
 being integrated now, perhaps that's something that can be reconsidered.

 I'm thinking that for folks using rpm, they'd rather see an update that
 pulls in the same fucntionality as they had before.  And even for new
 installs, I'd personally prefer to install these things via rpm.  If I
 wanted to use a secondary package management system, I could use gems or
 eggs or CPAN, but I don't. ;)


Note that as soon as you adopt environments, you end up having multiple
locations on disk that you want modules to be installed into, which doesn't
fit very well with traditional package management systems.





 I think it's good to split out these things, as it would allow us to
 properly add a nagios dep to the hypothetical puppet-module-nagios package.




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

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

[Nigel Kersten]

On Fri, Apr 13, 2012 at 12:06 PM, Ashley Penney apen...@gmail.com wrote:

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


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





 However assuming this is going ahead then I think the error message should
 probably for
 now tell the user that they've been moved AND spit out an appropriate
 commandline to
 immediately import the module to the right place.

 On Fri, Apr 13, 2012 at 1:55 PM, Michael Stahnke 
 stah...@puppetlabs.comwrote:

 For the next major Puppet version, code-named Telly, we have some
 changes coming.  This is the first in a series of emails around these
 changes and may require some input from the community.

 For Telly, the nagios types will be moved into a module.  This allows
 them to be iterated on in isolation from the rest of Puppet's core
 release cycle and process. In the future we have plans to move several
 other types into modules that can be individually maintained,
 improved, tested and used.

 The module for Nagios will be available on the Forge.

 The upgrade path is the thing we need some feedback about.  The basic
 steps to upgrade would be to setup a Telly master, and then install
 the Nagios module via the Puppet Module Tool, which ships integrated
 with 2.7.13+ and Telly.

 The only caveat with this is that if, in the past, you were relying on
 the Nagios types and forget to install that module (or are unable to
 for some reason), you would get a failure.  The best proposal we could
 come up with was to have the platform team add some code that lets the
 user know that the Nagios types have moved. This basically moves this
 into a 'fail-well' state.  We'll try to provide the best information
 possible to the end-user about what is going on.

 Is that an acceptable path moving forward?  Comments and discussion
 welcome.


 Mike Stahnke
 Community Manager

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


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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] New CA, why do clients with old certs still work?

[Nigel Kersten]

On Fri, Apr 13, 2012 at 11:40 AM, Chip Schweiss chip.schwe...@gmail.comwrote:

 I'm in the process of scalling my puppet master to two server with a
 separate CA.   My plan was to establish a new CA and reissue
 certificates.   Part way through the process I noticed a behavior that
 seems a bit alarming.

 With one of my clients pointing to the new CA and new Puppetmaster but
 with the old certificate I ran a 'puppetd --test --server
 puppet01.mydomain'

 I was expecting it to fail validation and then regenerate the client
 certificate.  However it ran without error.

 Thinking maybe it's still hitting the orginal CA, I backed-up and wiped
 the ssl dir on the puppetmaster and restarted the pupetmaster to generate a
 new CA.   The client still works.  There are no signed certificates for
 this client on either puppetmaster or CA now and it still runs.


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



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


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

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

Re: [Puppet Users] Puppet Beginners: New list suggestion?

[Nigel Kersten]

On Wed, Apr 4, 2012 at 1:22 PM, Mister IT Guru misteritg...@gmx.com wrote:
 Thanks for the replies from all the puppet lab guys, and the members of this 
 list. It really brighten my day to read all the responses. I've learnt that 
 maybe I'm not so stupid after all! Ah yes, and that a second list is a no 
 no!! (It wasn't my best suggestion, but the community helped me see the light)

 I am really looking forward to Integrated Platform Team Puppet are currently 
 working on.

 It goes without saying that the more content that gets gobbled up by google 
 and indexed, the more lonely newbies that will be rescued by that search bar.

 I do have a more confidence puppet. I hope I didn't panic any of Team Puppet, 
 you guys are doing a great job, honestly, I've had my butt pulled out the 
 fire a good few times because of my basic of the most basic puppet setup, so 
 I'm a fan

No apologies necessary at all, and certainly no panic :)

We also love hearing stories about Puppet pulling butts out of fires :)


 On 3 Apr 2012, at 21:13, Nigel Kersten wrote:


 We do want to be running this, primarily because we want to provide an 
 integrated platform that includes a bit more than just the QA site itself. 
 We'd like to be able to integrate profiles across the Forge, a QA site and 
 even the bug tracker.

 It would be great if you were on a QA site, asking questions about 
 developing modules, and to be able to see that the person answering your 
 question has published several awesome Puppet modules that are really 
 popular. Vice versa, it would be great to be able to look at a module and 
 see that the author is a highly engaged member of the community.

 So all in all, we do want to provide this as a service by us, and it's 
 difficult to get that level of integration with StackExchange.

 I would like to point out that we've got a growing ServerFault community 
 under the 'puppet' tag, and there are some great people answering Puppet 
 questions there.

 This is clearly an even more pressing need than we'd been thinking, so we're 
 going to try and accelerate this.


 --
 Nigel Kersten
 Product Manager, Puppet Labs

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Puppet Beginners: New list suggestion?

[Nigel Kersten]

 forums may just be a bit too good. I feel as if
 puppet is lacking a sort of nursery area. After all, everyone here is
 already a 'professional' or so we like to think!
 
  Would it be a good idea to have a puppet beginners list, where people
 can post dumb questions, and maybe have some patient people posting links
 to blog entries, you tube videos (something which I noticed is lacking for
 puppet, again making it hard for me to evangelise about it, to even get
 clients to look at it), and get up to speed with you guys.
 
  I would like a Puppet Nursery - Or failing that, can we get a puppet
 advance list? :)
 
  I'm just saying - It worked for a different project, that's part of how
 ubuntu started to take over the world, it just became accessible to the
 casual user. Well, there are a bucket load of causal professional linux
 admins, who I fear may dismiss taking up puppet because they just can't get
 the time together to learn or keep up with those who puppet 24/7
 
  It's just an observation, with a request thrown in - If I annoyed you,
 upset you, hurt your ego or made you feel bad in any way, I'm sorry. If you
 wish to take it up with me personally, no problem, have your people call my
 people, and we'll set up the meet - I'm a big guy so bring backup! (just
 kidding, love peace and all that!) - I'm hoping to stimulate some
 conversation and debate - how can puppet be one of the first thoughts in
 the mind of someone who wants to manage from a 2 to 2 thousands machines? -
 Reach a critical mass amount casual users? Worked for Facebook, Twitter -
 not so much for Nokia but you get the point.
 
  SO! Techie Admin Genius People!! Let's Debate
 
  --
  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.




 --
 http://aws.amazon.com/solutions/solution-providers/brandorr/

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Puppet Beginners: New list suggestion?

[Nigel Kersten]

On Tue, Apr 3, 2012 at 12:53 PM, Brian Gupta brian.gu...@brandorr.comwrote:

 On Tue, Apr 3, 2012 at 2:35 PM, Daniel Pittman dan...@puppetlabs.comwrote:

 On Mon, Apr 2, 2012 at 22:53, Denmat tu2bg...@gmail.com wrote:
  How about a 'serverfault' or 'stackoverflow' or the like site? One of
 the issues I find is that previous answers are lost in mail lists and hard
 to search for. IRC isn't much help for searching previous answers either.

 I would absolutely support getting a new StackExchange site for
 configuration management or something going.  What it really needs is
 someone to drive that forward - you can't just ask for one, it needs a
 community.


 Daniel, mmm.. do we want a general purpose configuration management site
 or a puppet specific one? I'd be willing to help host and setup a puppet
 specific one, however, I'd have thought that would be something that
 puppetlabs would want to own/run. Feel free to discuss internally, and let
 me know which way you guys want to go.


Hey Brian, thanks for the offer, it's much appreciated.

We do want to be running this, primarily because we want to provide an
integrated platform that includes a bit more than just the QA site itself.
We'd like to be able to integrate profiles across the Forge, a QA site and
even the bug tracker.

It would be great if you were on a QA site, asking questions about
developing modules, and to be able to see that the person answering your
question has published several awesome Puppet modules that are really
popular. Vice versa, it would be great to be able to look at a module and
see that the author is a highly engaged member of the community.

So all in all, we do want to provide this as a service by us, and it's
difficult to get that level of integration with StackExchange.

I would like to point out that we've got a growing ServerFault community
under the 'puppet' tag, and there are some great people answering Puppet
questions there.

This is clearly an even more pressing need than we'd been thinking, so
we're going to try and accelerate this.


-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Puppet Beginners: New list suggestion?

[Nigel Kersten]

On Tue, Apr 3, 2012 at 1:13 PM, Nigel Kersten ni...@puppetlabs.com wrote:


 On Tue, Apr 3, 2012 at 12:53 PM, Brian Gupta brian.gu...@brandorr.com
 wrote:

 On Tue, Apr 3, 2012 at 2:35 PM, Daniel Pittman dan...@puppetlabs.com
 wrote:

 On Mon, Apr 2, 2012 at 22:53, Denmat tu2bg...@gmail.com wrote:
  How about a 'serverfault' or 'stackoverflow' or the like site? One of
  the issues I find is that previous answers are lost in mail lists and hard
  to search for. IRC isn't much help for searching previous answers either.

 I would absolutely support getting a new StackExchange site for
 configuration management or something going.  What it really needs is
 someone to drive that forward - you can't just ask for one, it needs a
 community.


 Daniel, mmm.. do we want a general purpose configuration management site
 or a puppet specific one? I'd be willing to help host and setup a puppet
 specific one, however, I'd have thought that would be something that
 puppetlabs would want to own/run. Feel free to discuss internally, and let
 me know which way you guys want to go.


 Hey Brian, thanks for the offer, it's much appreciated.

 We do want to be running this, primarily because we want to provide an
 integrated platform that includes a bit more than just the QA site itself.
 We'd like to be able to integrate profiles across the Forge, a QA site and
 even the bug tracker.

 It would be great if you were on a QA site, asking questions about
 developing modules, and to be able to see that the person answering your
 question has published several awesome Puppet modules that are really
 popular. Vice versa, it would be great to be able to look at a module and
 see that the author is a highly engaged member of the community.

 So all in all, we do want to provide this as a service by us, and it's
 difficult to get that level of integration with StackExchange.

 I would like to point out that we've got a growing ServerFault community
 under the 'puppet' tag, and there are some great people answering Puppet
 questions there.

 This is clearly an even more pressing need than we'd been thinking, so we're
 going to try and accelerate this.

And to post the actual ServerFault link:

http://serverfault.com/questions/tagged/puppet





-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] X509v3 Subject Alternative Name in puppet generated certs...

[Nigel Kersten]

On Fri, Mar 9, 2012 at 6:15 PM, Jonathan Proulx j...@jonproulx.com wrote:

 I'm OK with flushing all my certs and starting over, but I have a
 couple of questions.  How does the puppet CA populate the altName
 field? and can I make it do what I want for both the CA and the non-CA
 servers or do I just need to suck it up, go get cozy with the openssl
 docs and do the server certs by hand if I want them fancy like that?

Jon, what version of Puppet are you running?

I can't seem to find a doc on this that isn't release notes, so we
should probably get a documentation bug in.

You can set 'dns_alt_names' either in your puppet.conf or on the
command line when the node generates a CSR.
Then you can use allow-dns-alt-names when signing the certificate on
the CA to approve those alt names.

Alternatively, you can use puppet certificate generate on the CA and
manually transmit the certificate/key to the node.

$ puppet help certificate sign
USAGE: puppet certificate sign [--terminus TERMINUS]
[--extra HASH]
--ca-location LOCATION
[--[no-]allow-dns-alt-names]
host

Sign a certificate signing request for HOST.

RETURNS: A string that appears to be (but isn't) an x509 certificate.

OPTIONS:
  --mode MODE- The run mode to use (user, agent, or master).
  --render-as FORMAT - The rendering format to use.
  --verbose  - Whether to log verbosely.
  --debug- Whether to log debug information.
  --[no-]allow-dns-alt-names - Whether or not to accept DNS alt names in the
   certificate request
  --ca-location LOCATION - Which certificate authority to use (local or
   remote).
  --extra HASH   - Extra arguments to pass to the indirection
   request
  --terminus TERMINUS- The indirector terminus to use.

TERMINI: ca, file, rest

See 'puppet man certificate' or 'man puppet-certificate' for full help.

-- 
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] hiera for defines?

[Nigel Kersten]

On Thu, Feb 23, 2012 at 5:21 AM, Markus Falb markus.f...@fasel.at wrote:


 And Question 3, finally: Does it make sense to you what I am trying to
 do, actually?


It feels significantly simpler for you to use hiera to pick out values that
you then pass to instances of defines, rather than baking hiera into the
definition of the define itself?

Might be easier to give advice if you post what the defined types that
you're planning to do this with actually do though?

-- 
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: Custom function issue

[Nigel Kersten]

On Wed, Feb 22, 2012 at 12:27 PM, DRivard dominick.riv...@gmail.com wrote:

 What is the purpose of running such function if they are not running
 on the client?


* Parsing/munging data in the manifests
* Collecting data from an external source to use in manifests
* Running a command on the master

It sounds like you want a custom fact instead of a function.





 On Feb 22, 3:22 pm, Gary Larizza g...@puppetlabs.com wrote:
  Hi there,
 
  So, functions will ALWAYS be executed on the Puppet MASTER server.
  They're
  never executed on the client.  This is why you're seeing the behavior
 that
  you do.
 
 
 
 
 
 
 
 
 
  On Wed, Feb 22, 2012 at 12:00 PM, DRivard dominick.riv...@gmail.com
 wrote:
   Hi,
 
   I needed a function to check if a file is existing on the Debian box I
   am configuring. So I used this one
 
   module Puppet::Parser::Functions
newfunction(:file_exists, :type = :rvalue) do |args|
  if File.exists?(args[0])
return 1
  else
return 0
  end
end
   end
 
   It work greats for some service where apache2 doesn't work for me.
   I am using it this way file_exists('/etc/init.d/apache2') == 1 if
   this return true I will stop the service or do nothing.
   In my case, the file /etc/init.d/apache2 exists on the puppet master
   running through Passenger, but the puppet client doesn't have it.
   But when I run the puppetd -vt it returns me an error because it's
   thinking the file /etc/init.d/apache2 exists on the puppet client and
   tries to stop the service.
 
   do you have any idea, is there a caching system on puppet client where
   we could delete a cached function?
 
   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.
 
  --
 
  Gary Larizza
  Professional Services Engineer
  Puppet Labs

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] puppet-forge.. do I remember correctly?

[Nigel Kersten]

On Mon, Feb 20, 2012 at 7:06 AM, Peter Berghold salty.cowd...@gmail.comwrote:

 Do I remember correctly that puppet-forge is no longer accepting uploads?


I don't think so. Did you run into a problem uploading?

-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] puppet-forge.. do I remember correctly?

[Nigel Kersten]

On Mon, Feb 20, 2012 at 8:35 AM, Peter Berghold salty.cowd...@gmail.comwrote:

 I most certainly did and immediately had a senior moment trying to
 remember if the puppet forge had be decommed in favor of github.


That's not going to happen, although we are looking at making it simpler
and more transparent for authors who are keeping their modules on github to
have automatic updates and publishing via the Forge view.



 Last night I tried uploading a module that I had written and cleaned up
 for public consumption and kept getting must be a tar.gz file error
 messages.   The file in question was a tar.gz file yet nothing I did seemed
 to fix the problem.  I'll try again later and see if I have better luck..


Please let me know if you're still hitting that, and we'll chase it up.





 On Mon, Feb 20, 2012 at 11:24 AM, Nigel Kersten ni...@puppetlabs.comwrote:



 On Mon, Feb 20, 2012 at 7:06 AM, Peter Berghold 
 salty.cowd...@gmail.comwrote:

 Do I remember correctly that puppet-forge is no longer accepting uploads?


 I don't think so. Did you run into a problem uploading?

 --
 Nigel Kersten
 Product Manager, Puppet Labs


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




 --
 Peter L. Berghold
 Owner, Shark River Technical Solutions LLC

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Search which the agent on which a specified module is been installed

[Nigel Kersten]

If you're happy with just knowing which machines will be told to install
that class/module, this information is available in your existing node
definitions and/or external node classifier too.

Note this is different from knowing which machines have actually had that
class/module applied, as some machines may not have contacted the master to
retrieve configuration yet.

On Wed, Feb 1, 2012 at 4:55 PM, Gary Larizza g...@puppetlabs.com wrote:

 Sateesh,

 You can use MCollective to get this bit of information if you do something
 like an mco find and limit it based on the class that's been applied to the
 machine with the -C argument.  That should return a list of nodes who have
 that class applied to it.  If you had a function in Puppet that returned
 this information, you could iterate upon it.

 -Gary


 On Wed, Feb 1, 2012 at 12:01 AM, sateesh bbalasate...@gmail.com wrote:

 Hi,

 Can we get the list of IPs from server where the specified module is
 installed. There is a search functionality in the Chef to do this. Is
 there any way in puppet?

 Thanks in advance,
 Sateesh B.

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




 --

 Gary Larizza
 Professional Services Engineer
 Puppet Labs

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Cross-module dependencies

[Nigel Kersten]

On Sat, Jan 28, 2012 at 10:39 PM, Brian Gupta brian.gu...@brandorr.comwrote:

 Nigel,

 It frightens me a bit that I think the correct solution, will be to
 replicate what the distros are doing in Puppetforge. Basically turning
 puppetforge into a massive cross distro metadata repo, with very strict
 contribution standards and rules. This would involve strong rules for
 curated modules that would require manpower to vet (and to contribute the
 modules).


It's worth pointing out here that a massive cross distro repository of
modules doesn't necessarily require strict contribution standards and rules.

There are other options to ensure that high quality modules are available
other than creating a high barrier to entry for the modules themselves.
Exposing community opinion on modules and success rates of people deploying
them can help us all achieve the same goal.

What kind of a repository do we want?

-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: constraint checking

[Nigel Kersten]

On Thu, Jan 26, 2012 at 6:19 AM, jcbollinger john.bollin...@stjude.orgwrote:



 On Jan 25, 10:53 am, Jo Rhett jrh...@netconsonance.com wrote:
  On Jan 25, 2012, at 8:30 AM, Nick wrote:
 
   But then I have to anticipate every possible value of $shell and define
   resources for them.  Anything which is not defined like this is not
 usable
   within the scheme, because there will be no file resource to realize
 and
   require.  And of course, it also means nothing else can say anything
 about any
   of these files without blowing up, because my code owns them.
 
   So far as I can see, this property of resources makes it hard to write
   self-contained and reusable modules, and this is frustrating.
 
  I just want to say +1 to this. I have found Puppet to be a wonderful way
 to deeply tie all your automation to an exact known configuration of hosts,
 but pretty much useless for dealing with situations in a generalized
 fashion. It is hard enough to track all the dependencies on modules being
 written by different people within the same team. I cannot image the pain
 which must be felt by people who have modules written by geographically and
 politically disperse teams.


It's actually not that bad at all from past experience when all the content
is being written in-house, even if the authors are organizationally,
politically and geographically disperse.

If you have dependencies upon foreign content you didn't author, express it
at the class level. This allows the other authors to refactor their own
classes internally, and not break your dependencies.

If you can't do this, one or both sides need to do refactoring so that it's
possible.

If you're building content you expect others to use more than once within a
given catalog, provide it in the form of defined types with well-named
parameters.

You do need to have a robust release process in place along the lines of
the classic dev - test - prod environments.

If your teams push out change at significantly different rates, you may
need to break up environments more to allow for this flexibility.


For the most part, I think this reflects the difficulty of the
 underlying problem more than any inadequacy of Puppet.  If multiple
 independent subsystems place different demands on the same resources,
 then you have a mess to sort out no matter what tools you use to do
 it.  On the other hand, if multiple independent subsystems place the
 same demands on certain resources, then that's pretty easy to handle,
 with Puppet or otherwise.

 That's not to deny that there is room for Puppet to improve here, but
 I suspect there is less room than you suppose.


+1

There are some things we could all do collectively to improve the
situation, particularly around pre-commit hooks to version control.

Functionality I've found useful in the past here was:

* check whether the changed manifests parse
* verify whether foreign class dependencies are fulfilled
* verify whether references to file sources actually exist

etc etc




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Cross-module (package) dependencies

[Nigel Kersten]

On Wed, Jan 25, 2012 at 9:59 AM, Ashley Penney apen...@gmail.com wrote:

 I don't have a solution but I do want to chime in and state that modules
 that
 exist just to collect together virtual resources is a horrible thing.
  We're just
 talking about working around the way Puppet works right now rather than
 defining what the end solution should be.


Absolutely right Ashley.

Please lets focus the conversation here on how things *should* be.



 I would be happiest with some kind of thing that can handle multiple
 versions
 of the same resource and work out a way to apply them as one entry.  Like
 others suggested something that can merge all the unique attributes
 together
 for one entry.  After all, if they've been included on the host all of
 those attributes
 should apply so I can't see a dangerous downside to this.

 It has to be better than trying to organize things so you only use a
 resource
 once and having all kinds of tricks and complicated workarounds.  I don't
 want
 my modules to have to rely on some weird generic module full of virtual
 resources
 just to use a package without clashing into a module written by a
 coworker.  I
 think modules should be capable, if possible, of standing alone, and this
 is ruining
 that basic concept.

 On Wed, Jan 25, 2012 at 12:12 PM, Dan Bode d...@puppetlabs.com wrote:



 On Tue, Jan 24, 2012 at 1:28 AM, Felix Frank 
 felix.fr...@alumni.tu-berlin.de wrote:

 Hi,

 there was a discussion in the can we deprecate defined() in Telly
 thread about how we can even begin to design Forge modules without it.

 A recurring problem is that multiple modules rely on certain packages,
 and there is no good model (yet) to unite their resource declarations.
 Therefore it's a common (although imho disgusting) workaround to do
 things like
 if !defined(Package[foo]) { package { foo: ensure = installed } }

 On 01/20/2012 11:34 PM, Cody wrote:
  Defining all somewhat common packages in a central location becomes
  unrealistic when you no longer control the code that is in every
  module you use.  If you obtain five modules from the forge and they
  all require a specific package and so all define that package your not
  going to convince, nor is it a good design to require everyone to move
  the package definitions from that collection of modules.  They need to
  function as a collection out of the box.

 Agreed. How can this be accomplished?

 Perhaps there needs to be some kind of Forge common module that by
 policy can only ever declare virtual resources (packages are a prominent


 Until there is a way to distinguish between collection of regular versus
 virtual resources, I hope that we don't do anything that advocates the
 usage of virtual resources.

 The problem is that collections (like below) meant to
 establish multiple dependencies unfortunately have the side effect of
 realizing virtual resources.

 Class['apt'] - Package| |


 example).
 A user who wishes to retain the capability of using modules from the
 Forge would be required to install this common module, and replace their
 own resource declarations with realizations of the common resources.
 For this to work, it's definitely a plus that you can override
 attributes in collections:
 Package| title == apache2: | { ensure = 2.2.12 }
 ...although that does bear some caveats. Does this still work in recent
 versions?

 If we can take this for granted, all Forge modules can adhere to that
 same standard.

 This is a rough sketch of how things might possibly work, and surely has
 lots of wrinkles of its own. Still, I'm quite sure we need a proper way
 to rid ourselves of the horror that is the parse order dependent check
 for defined resources ;-)

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


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


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




-- 
Nigel Kersten
Product Manager, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To post to this group, send email to puppet-users

Re: [Puppet Users] Issues with new puppet install...

[Nigel Kersten]

This looks like you've got a puppet agent that is newer than the version of
your master.



On Wed, Jan 25, 2012 at 12:36 PM, Peter Berghold salty.cowd...@gmail.comwrote:

 Just got done installing apache2, passenger, puppet, dashboard over the
 day...

 Ran my first puppetd --test and got the following:

 # puppetd --test
 info: Loading facts in root_home
 info: Loading facts in facter_dot_d
 info: Loading facts in concat_basedir
 info: Loading facts in root_home
 info: Loading facts in facter_dot_d
 info: Loading facts in concat_basedir
 warning: Not using cache on failed catalog
 err: Could not retrieve catalog; skipping run
 err: Could not send report: Error 405 on SERVER: !DOCTYPE HTML PUBLIC
 -//IETF//DTD HTML 2.0//EN
 htmlhead
 title405 Method Not Allowed/title
 /headbody
 h1Method Not Allowed/h1
 pThe requested method PUT is not allowed for the URL /production/report/
 slcupuppet.slc.sharkrivertech.com./p
 hr
 addressApache/2.2.17 (Ubuntu) Server at puppet Port 8140/address
 /body/html



 I'm not even sure where to look for this issue... I'm sure I missed
 something somewhere...


 --
 Peter L. Berghold
 Owner, Shark River Technical Solutions LLC

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Issues with new puppet install...

[Nigel Kersten]

do you have multiple versions of puppet installed?

If you're in bash:

$ type --all puppet{,d,masterd}

Do you get different versions returned for:

$ puppet --version
$ puppetd --version


On newer installs you should be using puppet agent instead of puppetd
(We moved to git-style subcommands a while ago)



On Wed, Jan 25, 2012 at 1:03 PM, Peter Berghold salty.cowd...@gmail.comwrote:

 master and agent are on the same box.  they should be the same version.



 On Wed, Jan 25, 2012 at 3:53 PM, Nigel Kersten ni...@puppetlabs.comwrote:

 This looks like you've got a puppet agent that is newer than the version
 of your master.



 On Wed, Jan 25, 2012 at 12:36 PM, Peter Berghold salty.cowd...@gmail.com
  wrote:

 Just got done installing apache2, passenger, puppet, dashboard over the
 day...

 Ran my first puppetd --test and got the following:

 # puppetd --test
 info: Loading facts in root_home
 info: Loading facts in facter_dot_d
 info: Loading facts in concat_basedir
 info: Loading facts in root_home
 info: Loading facts in facter_dot_d
 info: Loading facts in concat_basedir
 warning: Not using cache on failed catalog
 err: Could not retrieve catalog; skipping run
 err: Could not send report: Error 405 on SERVER: !DOCTYPE HTML PUBLIC
 -//IETF//DTD HTML 2.0//EN
 htmlhead
 title405 Method Not Allowed/title
 /headbody
 h1Method Not Allowed/h1
 pThe requested method PUT is not allowed for the URL
 /production/report/slcupuppet.slc.sharkrivertech.com./p
 hr
 addressApache/2.2.17 (Ubuntu) Server at puppet Port 8140/address
 /body/html



 I'm not even sure where to look for this issue... I'm sure I missed
 something somewhere...



 --
 Peter L. Berghold
 Owner, Shark River Technical Solutions LLC

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




 --
 Nigel Kersten
 Product Manager, Puppet Labs


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




 --
 Peter L. Berghold
 Owner, Shark River Technical Solutions LLC

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] My ENC won't work, YAML is valid AFAIK

[Nigel Kersten]

When you run your script by hand, does it exit 0 ?

Does it do so when the user you are running the master as (pe-puppet I
believe in this case) runs the script?



On Wed, Jan 25, 2012 at 3:15 PM, jblaine cjbla...@gmail.com wrote:

 If anyone has any ideas, please share.  I'm at a loss.

 YAML from Puppet Enterprise 2.0.0 default ENC:

 
 ---
 name: rcf-cm-master.our.org
 parameters: {}

 classes:
 - core-permissions
 

 YAML from my Python ENC using PyYAML.  This results in 'cannot find node'.

 
 ---
 classes:
 - core-permissions
 name: rcf-cm-master.our.org
 parameters: {}
 

 Note that putting the YAML output above in a file and loading it with
 Ruby's
 YAML::load does not throw an exception.

 I'm stumped :|

 --
 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/-/VChRtFes9wEJ.
 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Issues with new puppet install...

[Nigel Kersten]

ahah. I'm sorry, I sent you down completely the wrong path.

title405 Method Not Allowed/title
/headbody
h1Method Not Allowed/h1
pThe requested method PUT is not allowed for the URL /production/report/
slcupuppet.slc.sharkrivertech.com./p
hr

That error was for the report processor, not the catalog retrieval. I
apologize.

This is a bit Puppet Enterprise-specific, and should possibly go to the
pe-users list:

http://groups.google.com/a/puppetlabs.com/group/pe-users

but it looks to me like you've got permissions issues in auth.conf...

You haven't made any changes by hand yourself?


On Wed, Jan 25, 2012 at 1:57 PM, Peter Berghold salty.cowd...@gmail.comwrote:

 Just for completeness:

 # type --all puppet{,d,masterd}
 puppet is /usr/bin/puppet
 puppetd is /usr/bin/puppetd
 puppetmasterd is /usr/bin/puppetmasterd

 # puppet --version
 2.7.9


 # puppetd --version
 2.7.9

 # puppetmasterd --version
 2.7.9

 On Wed, Jan 25, 2012 at 4:37 PM, Peter Berghold 
 salty.cowd...@gmail.comwrote:

 There is only one version of puppet (agent and master) on the system.
 This system was installed from bare metal this morning.

 On Jan 25, 2012 4:24 PM, Nigel Kersten ni...@puppetlabs.com wrote:

 do you have multiple versions of puppet installed?

 If you're in bash:

 $ type --all puppet{,d,masterd}

 Do you get different versions returned for:

 $ puppet --version
 $ puppetd --version


 On newer installs you should be using puppet agent instead of puppetd
 (We moved to git-style subcommands a while ago)





 On Wed, Jan 25, 2012 at 1:03 PM, Peter Berghold salty.cowd...@gmail.com
 wrote:
 
  master and ...
 --
 You received this message because you are subscribed to the Google Groups
 Puppet Users group.
 ...




 --
 Peter L. Berghold
 Owner, Shark River Technical Solutions LLC

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] RFC: Deprecate defined() function for Telly.

[Nigel Kersten]

On Wed, Jan 25, 2012 at 5:25 PM, Ashley Penney apen...@gmail.com wrote:


 All I know is that telling users If you download 5 modules from puppet
 forge
 make sure you go through them all, extract any duplicating resources into
 random modules that exist purely to allow you to realize packages instead
 leads
 to a really bad user experience.


Absolutely. We're aware this is a big limitation for great collaboration on
module content, and it needs to be addressed.

Don't you think it makes more sense to make that part of module metadata
rather than trying to do it inside all your manifests?

If we have:

* puppet module tool supporting dependencies and generating module metadata
* classes not loading if their dependencies aren't satisfied (or at the
least big warnings)

do we really need defined()?


-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Cross-module (package) dependencies

[Nigel Kersten]

On Tue, Jan 24, 2012 at 4:42 AM, Walter Heck walterh...@gmail.com wrote:

 What if there was some standardised way modules expose a sort of list
 of requirements or an API of some sort?


I had this thought the other day, but more focused around the higher level
problem of dependency specification and consumption than Packages in
particular.

What if you made two functions:

1. declare_capability(foo)
  This would essentially just create an empty resource, Capability[foo]. If
multiple modules tried to declare the same capability, it would error, just
like we do today with duplicate resources.

2. require_capability(foo)
  This would just declare a requirement relationship to Capability[foo]. If
it couldn't find that resource, compilation would fail.


Wouldn't something like this solve the general problem? We don't really
want to just speak about packages, you generally want to be able to express
requirements like:

* This module requires a working SSH server
* This module requires a MySQL database

etc etc

I've deliberately focused this on doing this with functions as the
extension point as I think it keeps us focused, even if we decide that in
the future this should be solved in the metadata layer of a module.

-- 
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-module (package) dependencies

[Nigel Kersten]

On Tue, Jan 24, 2012 at 4:34 PM, Walter Heck walterh...@gmail.com wrote:

  I had this thought the other day, but more focused around the higher
 level
  problem of dependency specification and consumption than Packages in
  particular.
 Yeah, since that is something that is currently kind of difficult to
 implement properly. I'd welcome a proper way to do this.

  What if you made two functions:
 
  1. declare_capability(foo)
This would essentially just create an empty resource, Capability[foo].
 If
  multiple modules tried to declare the same capability, it would error,
 just
  like we do today with duplicate resources.
 
  2. require_capability(foo)
This would just declare a requirement relationship to Capability[foo].
 If
  it couldn't find that resource, compilation would fail.
 
 
  Wouldn't something like this solve the general problem? We don't really
 want
  to just speak about packages, you generally want to be able to express
  requirements like:
 
  * This module requires a working SSH server
  * This module requires a MySQL database
 
  etc etc
 
  I've deliberately focused this on doing this with functions as the
 extension
  point as I think it keeps us focused, even if we decide that in the
 future
  this should be solved in the metadata layer of a module.
 Hmm, while I can see your point of using functions, I think a more
 puppety way of doing this would be to have

 require Capability['yadda']

 vs

 capability{'yadda':
  ensure = present
 }


Yeah. I went for functions to try and hide the fact that this is a resource
underneath, but perhaps modeling this more transparently makes sense.



 We'd also need a way to test if a capability is being provided by the
 system as a whole. Ie, a mysql module needs to be able to check if it
 needs to include resources for a firewall, monitoring, etc.


Something like defined()? ;-)

-- 
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: How to handle multiple modules requiring the same packages

[Nigel Kersten]

On Wed, Jan 18, 2012 at 3:52 AM, Felix Frank 
felix.fr...@alumni.tu-berlin.de wrote:


 Is there a good reason that this function is even retained in recent
 versions of puppet? I have yet to encounter an instance where it can be
 used cleanly.


I'll start another thread about this, but I'd quite like us to deprecate it
for Telly.

-- 
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] RFC: Deprecate defined() function for Telly.

[Nigel Kersten]

I'm looking for strong opinions on whether we should or shouldn't deprecate
the defined() function for Telly, the next major Puppet release this year.

jcbollinger put it quite well in another thread:

Use of the defined function introduces a parse-order dependency, and the
additional work you need to do to ensure that that dependency is always
fulfilled overcomes any simplicity advantage that might otherwise exist.



-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?

[Nigel Kersten]

On Tue, Jan 17, 2012 at 9:33 PM, Ryan Bowlby rbowlb...@gmail.com wrote:

 Thanks for the great replies Nigel. As a person currently rolling out
 Puppet into production I'm stricken with doubt about how to best
 represent variables in a module. It would seem to me that I need to:

 1. set default values in params.pp (based on facts, yadda yadda)
 2. allow those values to be overridden by global namespace variables
 (for enc support)
 3. further allow parametrized class declarations to take precedence
 over 1 and 2

 Can you point me to a module that does this? Alternatively, can you
 make a recommendation for module best practices going forward.


Have you looked at Hiera yet Ryan? An awful lot of this is baked into it,
and you may find you don't need to set these at the ENC level.




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?

[Nigel Kersten]

On Mon, Jan 16, 2012 at 7:23 AM, Alessandro Franceschi a...@lab42.it wrote:


 On Sunday, January 15, 2012 9:30:02 PM UTC+1, Nigel Kersten wrote:


 So here's the rough idea we have in place.


 Let me contextualize: What you suggest here is what may be introduced in
 2.8 , when Hiera will be integrated into Puppet?


Yes, but Telly, not 2.8.

We may use Telly to fully adopt Semantic Versioning ( http://semver.org )
and take this opportunity to reset to 3.0.0 instead of 2.8.





 Parameterized class lookups are automatically consulted in a Hiera
 backend.

 The lookup order would be as follows:

 1. directly supplied value in the declaration of the class:
   class { foo: param = value }

 2. Hiera backend

 3. Default value supplied in the definition of the class:
   class foo ($param = value) { ... }

 This would happen automatically, without requiring the use of a hiera()
 like function in the class definition.


 +1
 I like the fact that this is transparent... if you have an Hiera backend
 then it's used, if not (or if you use an older Puppet version), normal
 behavior is followed.


Yep.



 It's clear that we need to have a way for module authors to specify values
 in the definition of the class.

 Is this satisfied well by having the values in the manifests themselves
 as in (3) above?


 Well a simple  class foo ($param = value) { ... } might not be enough,
 some logic (for example a different value for different operating systems)
 to give defaults values might be needed (back to params.pp ...)


 Or should we be encouraging authors to put a Hiera-style backend inside
 their modules and have that be consulted for default values?


 For me is saner to leave to puppet dsl the management of the values to
 attribute to these internal variables.
 It's how we always have done it and, for me, it works.


But this is really because there has been no other option right? It's never
really been easy for module authors to ship default data values inside
modules, but not in manifests.

I agree it works, but I'd like us to think about whether we can improve it.




 I'm not particularly fond of the work we're making people do around
 polluting the global namespace with class-specific data.
 That's something I think we should probably remove entirely, but open to
 suggestions.


 -1 if I understood well
 If you mean that you would remove the possibility to define top scope
 variables with custom names (ie things like ::monitor = true but also
 ::monitor_openssh = true) please let me know when and how this could happen.


No no no.

I more meant that we've had a whole lot of clustered behavior that has
meant we've forced people to use global namespace variables in say ENCs to
pass down to modules.

Users and authors shouldn't *have* to do that, and I'd like to make sure
we're giving people better options than always having to put everything in
top scope.


 As a user I'm not so fond of radical changes in the Puppet code that make
 unusable manifests made for earlier Puppet versions (hint: dynamic
 variables scoping no more possible in 2.8: I understand that they were a
 source of various problems, but that was just for users misuse due
 eventually to not clear enough directives/documentation/best practices).
 I understand that this is done for a better future and that
 retrocompatibility should not be a dogma, but... well... when I write some
 Puppet code I hope it's going to work for some years...


I'd argue that the dynamic variable scoping resulted in quite fundamental
problems, but yes, there's totally a balancing act here between progress
and compatibility.

-- 
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] pip provider

[Nigel Kersten]

On Mon, Jan 16, 2012 at 11:01 AM, Chris Blumentritt cblum...@gmail.comwrote:

 I am running puppet 2.7.9 and using the pip provider.

 The package gets/is installed but puppet installs it on every run.  Do
 other people run into this.  I tried search bugs and the group and
 have not seen any mention of it.


Can you do a run with --debug on and paste the relevant parts Chris?



-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Where to submit documentation request?

[Nigel Kersten]

On Mon, Jan 16, 2012 at 2:39 PM, Alan Evans alanwev...@gmail.com wrote:

 Is the puppet documentation still in git somewhere and I can just
 submit a pull request?  I that the section on undefined variables in
 the templating document was lacking.  When using paramaterized
 classes, default values for variables and has_variable?() the results
 may not be what one expects.  My co-worker was able to lead me to
 :undef symbol but it would be handy to have it on the page.

 http://docs.puppetlabs.com/guides/templating.html#undefined-variables


Here you go Alan:

https://github.com/puppetlabs/puppet-docs/blob/master/source/guides/templating.markdown






 Regards,
 -Alan

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Exec depends on ressources that are several different types

[Nigel Kersten]

On Sun, Jan 15, 2012 at 4:17 PM, Patrick Viet
patrick.v...@learnosity.comwrote:

 On Jan 11, 9:07 am, Aaron Grewell aaron.grew...@gmail.com wrote:
  require accepts an array, so you should be able to do this:
  require = [File['foo'],Exec['bar']]

 It worked. Thanks so much. I should submit this as an addition in one
 of the wiki examples on the puppet website.


Ideally submit it as a bug against this page:

http://docs.puppetlabs.com/guides/language_guide.html

here:

http://projects.puppetlabs.com/projects/puppet-docs/issues/new



-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: undefined method `pip' for #Puppet::Type::Package::ProviderPip

[Nigel Kersten]

On Sat, Jan 14, 2012 at 7:33 AM, Ahmed El-Gamil ahmedelga...@gmail.comwrote:

  Turns out that python-pip was not installed :)


Ahmed, can you please file a bug to improve the error message? We should be
able to tell you that python-pip isn't installed rather than an obscure
message like this :)

http://projects.puppetlabs.com/projects/puppet/issues/new




 --
 Ahmed El-Gamil

 On Saturday, January 14, 2012 at 5:21 PM, Ahmed El Gamil wrote:

 Hi Guys,

 Did someone fix that undefined method `pip' for
 #Puppet::Type::Package::ProviderPip error ? (check
 https://gist.github.com/1227739)

 I just faced the same error and i pretty much can't use puppet-pip at
 all now :/

 Puppet version: 2.7.6


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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?

[Nigel Kersten]

On Sat, Jan 14, 2012 at 2:09 PM, Alessandro Franceschi a...@lab42.it wrote:

 Gary has already given a good reply, let me just add some of the
 motivations that have driven this approach in my new modules (example42):
 - I want all the variables used in a Puppet class to be visible to the
 system (in my case Puppi, so that I can do interesting things with them):
 Puppet know so much about how a system is configured that I find it somehow
 reductive to use all this knowledge just to configure things :-)
 - Parametrized class are cool, but they can be a PITA to repeat every time
 you use them some common parameters (in my case if and how to monitor the
 class' resources, if to firewall it or activate puppi for it and so on)
 - In params.pp you can set default values and manage the differences among
 different operating system (which is something that the user should not
 care about) . I present these module internal variables  (such as
 packagename, processname, servicename and so on) as class parameters
 because I need them for my puppi things (look at what is done when puppi is
 set to true in https://github.com/example42/**puppet-openssh/blob/master/*
 *manifests/init.pphttps://github.com/example42/puppet-openssh/blob/master/manifests/init.pp
 )
 - Parametrized classes are cool but you can't (still) use them in the
 common ENCs around (PuppetDashboard, the Foreman). In Puppet AFAIK,
 extenarl nodes can have just some variables set and classes included.
 That's why I wanted to preserve the old style set variables+include class
 approach.
 Actually in my new modules you can mix global variables and class
 parameters seamlessly.

 All this approach requires some verbose extra code in params.pp but for me
 is worth the effort.
 Also Dan Bode has suggested to create a custom function that makes the
 same lookups for each parameter (params class, custom classes, top scope
 variables and hiera lookups) that would save a lot of extra code in
 params.pp . So there might be some further development in this area.


What would it take for you to just have one source of truth for data
Alessandro?

e.g. what would we have to change about Puppet for us to simply use Hiera ?

We're looking to integrate Hiera into Puppet for Telly, and in general
moving data outside of manifests has a lot of benefits, but I'm interested
to know whether you're of a similar mind with regard to the data you're
considering.


 Hope to have given reasonable answers ;-)
 al

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

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] How to handle multiple modules requiring the same packages

[Nigel Kersten]

On Fri, Jan 13, 2012 at 9:02 AM, bel belm...@gmail.com wrote:

 We have a database module and an application module that both require
 gcc. When I include both modules in a node, I get errors about the
 package being already defined.

 How would I address this?


Move the gcc package definition to a third module/class.

Tell both the db and app module that they require Class['gcc'].

Does that make sense?



-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Database calls in puppet manifests

[Nigel Kersten]

On Mon, Jan 9, 2012 at 12:13 PM, Jeff Sussna j...@ingineering.it wrote:

 This sounds like a fine solution. I won't have many, and easy enough
 to encapsulate the data access in a shell script, and it sounds like I
 can call generate directly from my template where I need the dynamic
 values.

 I may be getting greedy, but if a value doesn't change between runs,
 will Puppet be smart enough to know the file doesn't need to be
 updated on the client?


Yes.

If you're say using the database call to populate the contents of a text
file, and that content does not change between runs, Puppet on the client
will not update the file if the contents already match your desired state.





 On Jan 7, 10:57 am, Nigel Kersten ni...@puppetlabs.com wrote:
  On Fri, Jan 6, 2012 at 8:45 AM, windowsrefund windowsref...@gmail.com
 wrote:
 
 
 
   On Jan 6, 10:25 am, Jeff Sussna j...@ingineering.it wrote:
(How) do folks handle situations where puppet variables need to be
populated from dynamic database queries?
 
   Most folks do not. However, some have spawned a framework called
   hiera. By default, hiera uses a yaml backend but it can certainly be
   extended to query a database. In fact, I believe a mongo backend is
   out there somewhere.
 
   Of course, if you wanted, you could even write a custom function for
   the job. Hiera is probably a cleaner direction though.
 
  Another option is to use the generate() function on your master if you've
  already got a shell/executable script that can get the data for you.
 
  If you've got lots of these, it's probably not the best approach, but
 it's
  a lower barrier to entry if you're only doing one or two.
 
  --
  Nigel Kersten
  Product Manager, Puppet Labs

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] compliance baseline

[Nigel Kersten]

On Fri, Jan 6, 2012 at 11:54 AM, gen...@allantgroup.com 
andyr...@gmail.com wrote:

 I am trying to get my nodes to show how compliant they are to their
 baselines.  But, I cannot get even the baseline data to show up.  I
 have an audit class :

 class audits {
file{'/var/log/messages' :
audit = 'mode',
}
 }

 And I see that is is run because I see the audit change notification
 in the report logs for the node.  But nothing is showing up under the
 compliance tab on the dashboard.  What am I missing?  How does this
 table get populated?  I run puppet inspect on the command line of
 the node and all prints out is how long it took to run.  What am I
 doing wrong?


Hi Andy.

This is a PE specific feature, and should probably go to the pe-users list:

http://groups.google.com/a/puppetlabs.com/group/pe-users

There should be a cron job in place on your console machine that analyzes
the audit reports and constructs the baseline compliance data.

Did the relevant data start appearing the next day once the scheduled cron
job ran?

I've added a bug report that we need to cover the scheduled task in the
docs:

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


 Thanks,

 Andy

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Database calls in puppet manifests

[Nigel Kersten]

On Fri, Jan 6, 2012 at 8:45 AM, windowsrefund windowsref...@gmail.comwrote:



 On Jan 6, 10:25 am, Jeff Sussna j...@ingineering.it wrote:
  (How) do folks handle situations where puppet variables need to be
  populated from dynamic database queries?

 Most folks do not. However, some have spawned a framework called
 hiera. By default, hiera uses a yaml backend but it can certainly be
 extended to query a database. In fact, I believe a mongo backend is
 out there somewhere.

 Of course, if you wanted, you could even write a custom function for
 the job. Hiera is probably a cleaner direction though.


Another option is to use the generate() function on your master if you've
already got a shell/executable script that can get the data for you.

If you've got lots of these, it's probably not the best approach, but it's
a lower barrier to entry if you're only doing one or two.



-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Static Puppet Binary

[Nigel Kersten]

On Sat, Jan 7, 2012 at 9:34 AM, Mister IT Guru misteritg...@gmx.com wrote:

 Good Evening

 I just wanted to ask a question here, is it possible to build a static
 binary that I could sep to a client machine, and have it do it's first run
 to connect to a puppet master?

 My plan is to use a static binary as a sort of installer for particular
 systems, as I don't really want to have to install puppet client on 70
 systems by hand! These are all production servers already, so I'm not
 getting the opportunity to build them from the ground up.


Is it that much more difficult to push a package to a machine than it is to
copy a static binary to it?

If you download the source tarball for Puppet, you can use ext/envpuppet to
run Puppet directly out of the source tree, assuming that you've already
got Ruby on the machines.





 Any advice is appreciated, thanks.

 Mister IT Guru -- misteritg...@gmx.com
 Twittersphere @mritguru



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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Puppet agent hangs after running a few hours, defunct sh process

[Nigel Kersten]

On Thu, Jan 5, 2012 at 11:06 PM, Andreas N d...@pseudoterminal.org wrote:

 Wow, it took quite a while for my post to reach this group. No idea why,
 is it moderated?


We moderate the first post from everyone to stop spam getting through.

This sucks, but it sucks less than the other alternatives of moderating
every post, or approving membership manually.

-- 
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] Infiniband and Puppet - Strange Messages

[Nigel Kersten]

 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 Ifconfig uses the ioctl access method to get the full address
 information, which limits hardware addresses to 8 bytes.
 Because Infiniband address has 20 bytes, only the first 8 bytes are
 displayed correctly.
 Ifconfig is obsolete! For replacement check ip.
 info: Caching catalog for .y.com
 info: Applying configuration version '1325468978'
 notice: /File[/etc/yum.repos.d/x.repo]/ensure: current_value file,
 should be absent (noop) .
 .

 Any ideas on that ?

 Best
 Erhard

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Managing sensitive strings with puppet

[Nigel Kersten]

On Wed, Dec 28, 2011 at 9:06 AM, Ryan Stewart zzant...@gmail.com wrote:

 On Dec 27, 5:00 pm, Ryan Stewart zzant...@gmail.com wrote:
  Before jumping into hiera, I was trying to get a feel for extlookup()
  with CSV files because it looked pretty simple, but I can't seem to
  make it work.

 nm. I figured out what I was doing wrong.


What was it Ryan? Is there something we could do to improve the docs here?


-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Managing sensitive strings with puppet

[Nigel Kersten]

On Wed, Dec 28, 2011 at 11:05 AM, Ryan Stewart zzant...@gmail.com wrote:

 On Dec 28, 11:33 am, Nigel Kersten ni...@puppetlabs.com wrote:
  On Wed, Dec 28, 2011 at 9:06 AM, Ryan Stewart zzant...@gmail.com
 wrote:
   On Dec 27, 5:00 pm, Ryan Stewart zzant...@gmail.com wrote:
Before jumping into hiera, I was trying to get a feel for extlookup()
with CSV files because it looked pretty simple, but I can't seem to
make it work.
 
   nm. I figured out what I was doing wrong.
 
  What was it Ryan? Is there something we could do to improve the docs
 here?
 
 I believe the problem was that I was doing the extlookup() outside of
 any class, and I recently converted my puppet project to a module,
 which I'm running with puppet apply -e 'include ...', which, I
 assume, would only run things inside of classes and not other stuff in
 the manifests where the classes are. Therefore the lookup was never
 being done in the first place, explaining the complete lack of any
 debugging information. I'm still trying to feel my way around how
 things should be organized, and this had to roll around in my head a
 while before I made the connection.


ahah. Yeah, I've actually been thinking about this usability problem
recently.

If you have DSL code outside a class within a .pp file, if you use puppet
apply /path/to/my.pp you only evaluate the code outside the class. If you
use puppet apply -e 'include myclass' you only evaluate the code inside the
class.


-- 
Nigel Kersten
Product Manager, Puppet Labs

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

[Puppet Users] Re: Call for talks for the Configuration Management DevRoom at fosdem 2011

[Nigel Kersten]

On Mon, Dec 20, 2010 at 10:57 AM, James Turnbull ja...@lovedthanlost.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 **Call for talks for the Configuration Management DevRoom at fosdem 2011**

 FOSDEM 2011 - http://fosdem.org/2011/

 6 February 2011, 09:00 to 17:00, Brussels, Belgium

 Contact: fosdem2...@puppetlabs.com

 We will be holding a Configuration Management DevRoom at fosdem 2011 and
 are requesting abstracts for structured presentations now.

 Important information, dates:

? Submission deadline for abstracts: 2011-01-08


Reminder to everyone that the deadline is rapidly approaching, and we're
filling up the room quickly!







? Notification of accepted speakers: 2011-01-10

? Final schedule: 2011-01-11

 **About this DevRoom**

 Configuration Management is exciting!  It is. Really. There is huge
 interest in automation, configuration management and especially PAAS,
 SAAS, IAAS and the cloud generally.  We're seeking people who are
 working the field, interested in the field, or just interested in
 learning more about how to make their lives easier with automation and
 configuration management.

 We invite you to submit talks on these topics:

 * Configuration Management theory principles
 * Configuration Management tools - real world use cases
 * Tools, techniques and case studies
 * Configuration Management and the Cloud
 * Configuration Management, Compliance and Security

 NOTE:  Puppet Labs is helping organise this room but we're looking for
 talks on more than Puppet!  We're looking for CFengine, Chef, bcfg2,
 AutomateIT, and the myriad of other tools out there.

 ** Your submission must include:**

* Your name

* The title of your talk

* A short abstract of one to two paragraphs (150 words, max.)

* A short biography

* Links to related websites/blogs etc.

 Send the abstracts to:

 fosdem2...@puppetlabs.com

 Presentations are to be formal and not longer than 30 minutes, plus 15
 extra for questions (45 in total). Panels with more than one speaker are
 something we're also seeking, a My configuration management tools is
 the awesomest and I'll debate that! is possible, as are shorter
 presentations of 20 minutes.  We're also exploring some un-conference
 style presentations too.

 The deadline for submissions is January 8th 2011 December 2010. If your
 proposal has been accepted, you will be informed by email by January
 10th 2011.

 Please feel free to forward this call for abstracts and papers to
 relevant lists, people and sites. We're looking forward to seeing lots
 of interested folks, have lots of spirited presentations, debates,
 discussion and ... quite possibly drinking.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQEVAwUBTQ+nECFa/lDkFHAyAQLAkAgAn0/kRQUnDETXMAkGDA8mexVP4d0p/qLX
 bRa1LGAqSdpKFCm6k6dUvWpgoEThiIXpQCZyvPnAWu/b25u+UcUFwllE7gJb4Ydu
 tGZ5N7ubP4Lp6BIj49k5efQdXF0MoEtSK0kdmQD9xcuhLV4FdrETRreYzQnW+64W
 /pSssvLpj1GaVfulTiJsXWVyFiQqnewRpz7Ap/UjNKHvAJrUlXmMqNkDVpqa4gGw
 gRL9EznlCBb+k39piIVjsuvhpS4mG2Cc6Vq9gGhZYDowvRMLWZ/7uZiknnUjZnDf
 mHDbkMhlovPZCYlRKmZnmxu6LYqB/QIiaxH4yc1q5afKZYxHB/dnvQ==
 =oror
 -END PGP SIGNATURE-




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

[Puppet Users] Re: Call for talks for the Configuration Management DevRoom at fosdem 2012

[Nigel Kersten]

*AHEM*

I accidentally replied to the call for papers from *LAST* year.

I blame the holiday season and concern over how Australia is doing in the
cricket.

We are running the room again, and we are looking for papers for *2012*
FOSDEM.



On Tue, Dec 27, 2011 at 3:23 PM, Nigel Kersten ni...@puppetlabs.com wrote:



 On Mon, Dec 20, 2010 at 10:57 AM, James Turnbull 
 ja...@lovedthanlost.netwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 **Call for talks for the Configuration Management DevRoom at fosdem 2011**

 FOSDEM 2011 - http://fosdem.org/2011/

 6 February 2011, 09:00 to 17:00, Brussels, Belgium

 Contact: fosdem2...@puppetlabs.com

 We will be holding a Configuration Management DevRoom at fosdem 2011 and
 are requesting abstracts for structured presentations now.

 Important information, dates:

? Submission deadline for abstracts: 2011-01-08


 Reminder to everyone that the deadline is rapidly approaching, and we're
 filling up the room quickly!







? Notification of accepted speakers: 2011-01-10

? Final schedule: 2011-01-11

 **About this DevRoom**

 Configuration Management is exciting!  It is. Really. There is huge
 interest in automation, configuration management and especially PAAS,
 SAAS, IAAS and the cloud generally.  We're seeking people who are
 working the field, interested in the field, or just interested in
 learning more about how to make their lives easier with automation and
 configuration management.

 We invite you to submit talks on these topics:

 * Configuration Management theory principles
 * Configuration Management tools - real world use cases
 * Tools, techniques and case studies
 * Configuration Management and the Cloud
 * Configuration Management, Compliance and Security

 NOTE:  Puppet Labs is helping organise this room but we're looking for
 talks on more than Puppet!  We're looking for CFengine, Chef, bcfg2,
 AutomateIT, and the myriad of other tools out there.

 ** Your submission must include:**

* Your name

* The title of your talk

* A short abstract of one to two paragraphs (150 words, max.)

* A short biography

* Links to related websites/blogs etc.

 Send the abstracts to:

 fosdem2...@puppetlabs.com

 Presentations are to be formal and not longer than 30 minutes, plus 15
 extra for questions (45 in total). Panels with more than one speaker are
 something we're also seeking, a My configuration management tools is
 the awesomest and I'll debate that! is possible, as are shorter
 presentations of 20 minutes.  We're also exploring some un-conference
 style presentations too.

 The deadline for submissions is January 8th 2011 December 2010. If your
 proposal has been accepted, you will be informed by email by January
 10th 2011.

 Please feel free to forward this call for abstracts and papers to
 relevant lists, people and sites. We're looking forward to seeing lots
 of interested folks, have lots of spirited presentations, debates,
 discussion and ... quite possibly drinking.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQEVAwUBTQ+nECFa/lDkFHAyAQLAkAgAn0/kRQUnDETXMAkGDA8mexVP4d0p/qLX
 bRa1LGAqSdpKFCm6k6dUvWpgoEThiIXpQCZyvPnAWu/b25u+UcUFwllE7gJb4Ydu
 tGZ5N7ubP4Lp6BIj49k5efQdXF0MoEtSK0kdmQD9xcuhLV4FdrETRreYzQnW+64W
 /pSssvLpj1GaVfulTiJsXWVyFiQqnewRpz7Ap/UjNKHvAJrUlXmMqNkDVpqa4gGw
 gRL9EznlCBb+k39piIVjsuvhpS4mG2Cc6Vq9gGhZYDowvRMLWZ/7uZiknnUjZnDf
 mHDbkMhlovPZCYlRKmZnmxu6LYqB/QIiaxH4yc1q5afKZYxHB/dnvQ==
 =oror
 -END PGP SIGNATURE-




 --
 Nigel Kersten
 Product Manager, Puppet Labs





-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] PE 2.0 server and regular stock puppet client

[Nigel Kersten]

On Sat, Dec 24, 2011 at 6:27 PM, John Burbridge johnburbri...@gmail.comwrote:

 Hello there,

 I'm having exactly the same issue except I'm trying to install puppet via
 cloud provisioning... but I think I might have messed up something along
 the way.

 My first install was successful except I didn't provide a certname
 parameter while running puppet node init and the default generated was
 appended with a long hash of some sort:

  www-dev2.home.mydomain.net-6d5aac9e-9f76-36e8-7d63-808bdf901c36

 Despite functional, that's not exactly what I wanted so I revoked the cert
 on the puppetmaster, re-installed, signed the new cert on the puppetmaster
 and now am getting the exact message described before:

 root@www-dev2:~# puppet agent --test
 warning: peer certificate won't be verified in this SSL session
 info: Caching certificate for www-dev2
 info: Retrieving plugin
 info: Loading facts in facter_dot_d
 info: Loading facts in facter_dot_d
 err: Could not retrieve catalog from remote server: Error 400 on SERVER:
 validate_re():  does not match ^true$|^false$ at
 /opt/puppet/share/puppet/modules/pe_mcollective/manifests/init.pp:40 on
 node www-dev2
 warning: Not using cache on failed catalog
 err: Could not retrieve catalog; skipping run


 I assume my condition is different from the original poster's given I'm
 attempting to spool up a new server using cloud provisioning with PE? Any
 thoughts on what my next steps should be?


This is getting a little far off field for puppet-users, and should
probably go to pe-users as it's very PE specific.

https://groups.google.com/a/puppetlabs.com/group/pe-users/topics

but it looks like you don't have the facts text file in place in
/etc/puppetlabs/facts.d that the PE installer lays down? That failure is
the module validating that the required input data is there, and it's not.
:)







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

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Recommendation for general practice for application deployment?

[Nigel Kersten]

Yep. Just checking whether there was a valid reason.

I've seen people avoid hot deploy even when they've got more than enough
resources to cope with individual apps hot-deploying.



On Fri, Dec 23, 2011 at 12:28 PM, Ken Barber k...@puppetlabs.com wrote:

 Hot-deploy can be risky. The biggest issue I've seen is a low permgen. Hot
 deploy puts twice the requirement on permgen.
 On Dec 23, 2011 7:58 PM, Kenneth Lo k...@paydiant.com wrote:

  “What are the problems this requirement is intended to solve?”





 What I was told from my eng team is that tomcat’s hot-deployment for our
 app will eventually break, so we want to always make sure tomcat is stop
 before the deployment, and starting up fresh.



 We will probably go with Doug’s suggestion earlier and re-package our app
 and process via rpm directly.



 --KL



 *From:* puppet-users@googlegroups.com [mailto:
 puppet-users@googlegroups.com] *On Behalf Of *Nigel Kersten
 *Sent:* Friday, December 23, 2011 2:00 PM
 *To:* puppet-users@googlegroups.com
 *Subject:* Re: [Puppet Users] Recommendation for general practice for
 application deployment?





 On Tue, Dec 20, 2011 at 8:26 AM, Kenneth Lo k...@paydiant.com wrote:

 Hi:



 I have a pretty general high-level question regarding application
 deployment using puppet infrastructure.



 Being new with puppet here we have a pretty simple module setup where we
 are utilizing a basic package-file-service combo for an tomcat application
 server, and with some additional war files for our apps.



 One of the engineering requirement regarding app deployment is to make
 sure tomcat shutdown cleanly before we move in with the new app war files.



 What are the problems this requirement is intended to solve?











 The way we handle new app release is via file resource that point to
 different puppet source based on the release tag.



 So the question is, given the service resource is also within the same
 module with the file, how do I make sure we can do the following
 sequentially?:



 1. Shutdown the tomcat instance (service resource in tomcat module)

 2. Update the application war file  (file resource in tomcat module)

 3. Start the tomcat instance



 We've been using mcollective to manually shutdown the service before
 applying puppet run, but I'm not sure if the sequence is correct. Thanks in
 advance.





 --KL

 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise private information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the email by you is prohibited.

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





 --
 Nigel Kersten
 Product Manager, Puppet Labs

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

 No virus found in this message.
 Checked by AVG - www.avg.com
 Version: 2012.0.1901 / Virus Database: 2109/4698 - Release Date: 12/23/11
  This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise private information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the email by you is prohibited.

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

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Managing sensitive strings with puppet

[Nigel Kersten]

On Thu, Dec 22, 2011 at 12:00 PM, Ryan Stewart zzant...@gmail.com wrote:

 I'm new to Puppet, and I'm a software developer, not a sysadmin, so be
 gentle. I have puppet managing some files via templates, and one of
 the template variables that needs to be plugged in is a password of
 sorts that shouldn't be generally available. In particular, it can't
 be stored in the manifest, as that's stored in version control, and
 the password shouldn't be available there. Basically, the only place
 it's okay for this password to be stored is on the systems that will
 be using it.

 What would be the Puppet way of getting this string into the
 configuration?


http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/

Does that help?

I've done this in the past without hiera, where you have a function that
runs on the master to decrypt the content out of version control, but the
above makes it pretty simple.

-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Recommendation for general practice for application deployment?

[Nigel Kersten]

On Tue, Dec 20, 2011 at 8:26 AM, Kenneth Lo k...@paydiant.com wrote:

  Hi:

  I have a pretty general high-level question regarding application
 deployment using puppet infrastructure.

  Being new with puppet here we have a pretty simple module setup where we
 are utilizing a basic package-file-service combo for an tomcat application
 server, and with some additional war files for our apps.

  One of the engineering requirement regarding app deployment is to make
 sure tomcat shutdown cleanly before we move in with the new app war files.


What are the problems this requirement is intended to solve?






  The way we handle new app release is via file resource that point to
 different puppet source based on the release tag.

  So the question is, given the service resource is also within the same
 module with the file, how do I make sure we can do the following
 sequentially?:

  1. Shutdown the tomcat instance (service resource in tomcat module)
 2. Update the application war file  (file resource in tomcat module)
 3. Start the tomcat instance

  We've been using mcollective to manually shutdown the service before
 applying puppet run, but I'm not sure if the sequence is correct. Thanks in
 advance.


  --KL
 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise private information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the email by you is prohibited.

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Best practice for module params in foo::params

[Nigel Kersten]

On Thu, Dec 22, 2011 at 6:54 AM, Walter Heck walterh...@gmail.com wrote:

 Hmm, that's the second time in two weeks someone mentions hiera as a
 solution for a problem that cannot easily be solved inside puppet, I guess
 it's time to go check it out :)


We're committed to Hiera, and are looking to integrate it as a first class
citizen by the next major release.

Totally go check it out :)

http://projects.puppetlabs.com/projects/hiera

-- 
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 Labs Newsletter coming to Puppet Users list

[Nigel Kersten]

I wanted to give you all a heads up that we're going to start sending our
Puppet Labs Newsletter to the puppet-users list once a month.

You can see older versions here:

http://puppetlabs.com/resources/newsletter/

You'll see from the other versions that each month we cover the whole
Puppet ecosystem, meetups, blogs from the community, and all sorts of
interesting Puppet related items.

We do want contributions from the community. We're very keen on getting the
best of the work that you all do highlighted here as we have a wider
readership than just the mailing list community. You all do lots of awesome
things, and we'd love to promote that.

If you create Puppet content yourself in the form of Puppet Modules on the
Forge or blog posts, if you give talks on IT automation at conferences, or
simply come across really interesting items that you think would be of
interest to the community, please let us know!

Send submissions to us at:

scott.johns...@puppetlabs.com

or if Twitter is more your thing, feel free to let us know via the
@puppetlabs account:  https://twitter.com/puppetlabs



-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: restarting service when configuration changes

[Nigel Kersten]

On Fri, Dec 16, 2011 at 5:57 AM, jcbollinger john.bollin...@stjude.orgwrote:



 On Dec 15, 8:13 pm, Nigel Kersten ni...@puppetlabs.com wrote:

  You can notify a class, and it forwards the signal to resources it
 contains.- Hide quoted text -


 I stand corrected.

 So, Nigel, do you have any idea why the OP's manifest is not doing
 what he expects?


Nope :)

What version of Puppet is this?

Can we see the relevant debug output of this manifest?

Does the service have a working restart command?

If you put a simple test refreshonly Exec into the class, does it get
notified?

-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: restarting service when configuration changes

[Nigel Kersten]

On Thu, Dec 15, 2011 at 2:56 PM, jcbollinger john.bollin...@stjude.orgwrote:



 On Dec 15, 10:16 am, Sans r.santanu@gmail.com wrote:
  On Dec 15, 2:08 pm, jcbollinger john.bollin...@stjude.org wrote:
 
   On Dec 14, 4:37 pm, Jo Rhett jrh...@netconsonance.com wrote:
 
Try
notify = Service['autofs']
 
   Right.  As far as I know, classes do not forward signals to resources
   they contain.
 
  Are you absolutely sure about that?


 As far as I know was meant to convey that no, I am not absolutely
 sure.



You can notify a class, and it forwards the signal to resources it contains.

-- 
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: Puppet Dashboard; node.rake

[Nigel Kersten]

Nice work Stefan!

(as an aside, we keep digging up positive contributors named Stefan in
the Puppet community. If this trend continues, I expect 90% of posts to be
from a Stefan in 12 months time ;-) )

I've cc'd Dan and Kelsey, who have both been working on a Dashboard Puppet
Face for command-line control. Although the rake tasks are totally useful,
we'd like to be able to have all this functionality under a puppet
dashboard ... set of commands.


On Sat, Dec 10, 2011 at 1:08 PM, Stefan Heijmans heijm...@rechtspraak.nlwrote:

 Finally found out how it worked, I've create a 2 new rake tasks (all or by
 match) to display a
 fulllist of nodes with
 Nodename : node
 Params   : param1=value1,param2=value2
 Groups   : group1,group2,group3
 Classes  : class1,class2,class3

 fulllist of groups with
 Group   : group
 Params  : param1=value1,param2=value2
 Classes : class1,class2,class3
 Nodes   : node1,node2,node3

 Now I can easily search where what is used.
 I've attached the rake file if people want to use it.

 Stefan

 --
 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/-/0bl7zHa0ukgJ.

 To post to this group, send email to puppet-users@googlegroups.com.
 To unsubscribe from this group, send email to
 puppet-users+unsubscr...@googlegroups.com.
 For more options, visit this group at
 http://groups.google.com/group/puppet-users?hl=en.




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: Is puppet right for us?

[Nigel Kersten]

On Thu, Dec 8, 2011 at 9:29 AM, Luke lutay...@gmail.com wrote:

 Ok a better way to word this can puppet allow us to isolate down the
 environment so that dev can make changes to their own environment but
 not QA, Prod etc.


Yes. In Puppet these are called environments :)

http://docs.puppetlabs.com/guides/environment.html

The standard way of achieving your goal is to set up your master to
synchronize different branches in your version control system to different
environments, and then set up ACLs on your version control such that only
approved folks can commit to each branch.

A particularly common pattern is to have environments for dev, test and
prod, where developers can only commit to dev, and ops are responsible
for propagating changes into test and then into prod.





 I am struggling with comparing these products because I don't think
 any one of them really does a good job of explaining what they do or
 how they go about doing it.


 On Dec 8, 1:16 pm, Luke lutay...@gmail.com wrote:
  Thanks guys.
 
  I should have pointed out that the developers do have builds mostly
  automated using ant we were just wondering we could have a solution
  that we could all use to try to standardize things. So I take it that
  we should probably just stick with that and perhaps look to puppet for
  our server builds?
 
  On Dec 7, 6:29 pm, Jon Davis j...@snowulf.com wrote:
 
 
 
 
 
 
 
   On Wed, Dec 7, 2011 at 12:22, Luke lutay...@gmail.com wrote:
 
 to automate our complex server builds
 
   Well, that's Puppets core skill.
 
and web app deployments but will assist our devs with getting their
 builds
ready to deploy
 
   Depends on how you deploy your webapps and your builds, it could, but
 it
   might not be the best solution.  I use puppet to run my web servers,
 but I
   use it in more of an Apache, create websites X, Y  Z fashion. Part
 of
   that process does create all the requisite folders and setup an rsync
 from
   the web master share to all the web servers.  So, in effect puppet is
   controlling it all, but really it is up to the devs to not screw up
   deploying their code to the share.
 
. Monitoring, integration of
Tomcat, mysql etc would be nice as well since configuring nagios is a
pain.
 
   Integrating Nagios has been done before, so you shouldn't have trouble
   finding examples.  But Puppet isn't going to monitor itself, of
 course.
 
   Can puppet do all of these things? Does it sound right for us?
 
We are also considering CFengine and Chef. Would puppet be a better
fit over these two? If so why?
 
   I think all 3 options are fairly similar (I just recently went digging
 for
   automation tools myself, and settled on Puppet).  Each one has their
   strengths and weaknesses.
 
   --
   Jon
   [[User:ShakataGaNai]] / KJ6FNQhttp://
 snowulf.com/http://www.linkedin.com/in/shakataganai
 http://twitter.com/shakataganai

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Re: How to import variables from another manifests/file??

[Nigel Kersten]

On Mon, Dec 5, 2011 at 3:31 AM, Sans r.santanu@gmail.com wrote:

 Thanks Nigel! That works like a charm. But leaves me with one question
 and another problem. First the question: If I always need to specify
 the varable like $zmfs::settings::l_dir, then waht the significance
 of the include statement (e.g. include zmfs::settings ) in the
 beginning of the manifest?


Including the class is what will cause the manifests in that class to be
evaluated. Does that help?



 Now the problem is: If I define env_check inside a
 'class' (envcheck.pp in my example code above) and specify include
 zmfs::envcheck in the config.pp, I get this error:


Make sure the names are the same.

e.g. a define called zmfs::envcheck should be in

$modulepath/modules/zmfs/manifests/envcheck.pp

It looks like you're mixing an extra underscore in there.

If you're doing this with a *define*, then you don't need to import or
include that specific file.  Just declare it in that location, and not
inside a class.

When you use that define, so long as the define is found in a path like the
one above where the autoloader will find it, you don't need to import or
include zmfs::envcheck anywhere.





 -
 err: Could not retrieve catalog from remote server: Error 400 on
 SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError:
 Invalid resource type line_check at /etc/puppet/modules/zmfs/manifests/
 config.pp:94 on node farm002.. .. ..ac.uk
 -

 It only works if the envcheck.pp like this way:


 
   # /modulepath/modules/zmfs/manifests/envcheck.pp:

define env_check($file, $string, $swdir, $refreshonly = 'true') {
..
..
}
 

 (i.e. without having a class) and use import  envcheck.pp, instead
 of: include zmfs::envcheck in the manifest. Does any one know what's
 going wrong?

 Cheers,
 San


 
  You want to use $zmfs::settings::l_dir
 
  You're fully qualifying the variable, so you need the full path to it,
  including the name of the module it lives in.
 
  --
  Nigel Kersten
  Product Manager, Puppet Labs

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




-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Puppet Dashboard Questions

[Nigel Kersten]

On Mon, Dec 5, 2011 at 1:01 PM, hai wu haiwu...@gmail.com wrote:

 I quote what Nigel mentioned before:

 We'll have this ready within the next two Dashboard point releases.

 What's the state for this one (To report 'noop' mode puppet run)? Is
 this feature available in some dashboard release as of now?


Yes. The current release of Dashboard will show a noop run that has
simulated the run and identified changes that would be made under the
category Pending in the left-hand sidebar.


-- 
Nigel Kersten
Product Manager, Puppet Labs

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

Re: [Puppet Users] Puppet Dashboard Questions

[Nigel Kersten]

On Mon, Dec 5, 2011 at 4:49 PM, hai wu haiwu...@gmail.com wrote:

 Great! Is there any API to use to retrieve these information from
 dashboard database, so that we could generate a nice report via email,
 with short and verbose versions for such report?


No. You'd need to put together your own report processor that generated
these for you.

http://docs.puppetlabs.com/dashboard/ui/1.2/node_status.html

That shows you how the Pending status is determined.

In the libdir you can see how report processors are put together, and you
can send reports to multiple such processors.

https://github.com/puppetlabs/puppet/tree/master/lib/puppet/reports/

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