On 18 January 2013 09:14, Ashley Gould wrote:

But why so many methods? Why is there not a single recommended best
practice method for managing puppet.conf?

ANSWER: Because puppet.conf lacks an include statement.

So, we generate puppet.conf at jumpstart/kickstart and never ever touch it
again, so I don't quite understand why you need to manage it...

Sorry for the rant. I'm sure the above suggestion would have issues
too. I'm now on my 3rd major overhaul of our puppet infrastructure
classes solely because of this one file. I refuse to believe this is a
conspiricy just to get us to purchase PE. But there must be a better
This is what we have:
* External node classifier - you really do need one of these (IMHO)
* Web interface to ENC
* Wrapper script to puppet agent called by cron
* We query the ENC when we generate puppet.conf at jumpstart/kickstart

The wrapper script does a wget to the ENC for the host to determine its
environment and location. From that it determines what its puppet server/CA
server is. All servers (puppet, report, CA) are CNAMEs

The only time we ever regenerate a puppet.conf is if we move the server
in/out of lab as our lab has separate puppet server/CA/report to production


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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 4 | next ›
Discussion Overview
grouppuppet-users @
postedJan 17, '13 at 10:14p
activeJan 19, '13 at 6:11p



site design / logo © 2021 Grokbase