On 18 January 2013 09:14, Ashley Gould <ago...@ucop.edu> 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 > way. > 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 John -- 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.
