Puppet users - Jan 2013 - How do I manage puppet.conf? Let me count the ways.

In a recent post Nikola Petrov summerized methods for managing config
files such as puppet.conf:

* use augeas with virtual resources
* use the concat module
* use the standard template function with multiple arguments; look at
  http://docs.puppetlabs.com/guides/templating.html and scroll down to
  "Combining templates"


I can add a few others:

* use the ini_setting type puppetlabs/inifile
* tweek startup process of puppet master to use alternate config file
* append templates for agent and master in a puppet server class


We are an ingenious community.  I''m sure there are even more solutions
in circulation.  But none of these are trivial, and definitely not
newbie friendly. They are all created out of struggle and pain, because
for every server enhancement (storeconfigs, dashboard, puppetdb, etc.)
we have to docter our puppet.conf management method to accomodate some
additional options which really ought to be managed within an
enhancement specific class.

This makes it especially hard to make use of puppet forge modules.  For
example, it is not possible to combine puppetlabs/puppetdb with
example42/puppet without major revisions.  puppetlabs uses inifile.
example42 uses template.


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.


imagine:

# puppet.conf
[main]
    logdir = /var/log/puppet
    rundir = /var/run/puppet
    confdir = /etc/puppet
    environment = test
    include $confdir/conf.d/main/*

[agent]
    classfile = $vardir/classes.txt
    localconfig = $vardir/localconfig
    ca_server = puppet.blee.edu
    server = puppet.blee.edu
    include $confdir/conf.d/agent/*

[master]
    ca_server = puppet.blee.edu
    server = puppet.blee.edu
    include = $confdir/conf.d/master/*

include $confdir/conf.d/environments/*
# end puppet.conf

ls -1 /etc/puppet/conf.d/master
dashboard
puppetdb
reports
storeconfig


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.




-- 

-ashley

Did you try poking at it with a stick?

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

On 18 January 2013 09:14, Ashley Gould <agould@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 1/17/2013 2:14 PM, Ashley Gould wrote:
> 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.
Oh good, I''ve been wanting to rant about this myself. However I have a 
different take. Why do people insist on managing the agent and the 
master in the same config file?

Stop it. It''s complicated, brittle, and ultimately unnecessary.

	A production Puppet master is usually running behind Apache/Passenger 
or some other workalike. If you are still using webrick, you do not have 
a production quality master and I don''t care how you manage it. 
Regardless of the http server you''re using, your config.ru allows you
to
manage the config of your Puppet master. You can use this to point the 
master to its own config file.

ARGV << "--config=/etc/puppet/puppetmaster.conf"

Once you''ve done this separating into modules/puppet/ and 
modules/puppetmaster/ starts to make sense as well.

Ramin

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

On 01/18/2013 12:23 AM, Ramin K wrote:
> Once you''ve done this separating into modules/puppet/ and
> modules/puppetmaster/ starts to make sense as well.
Your advice is nice, although dot.d inclusion would still be better :)

Is there already request for feature?


-- 
Jakov Sosic
www.srce.unizg.hr

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