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

Search Discussions

  • John Warburton at Jan 17, 2013 at 10:26 pm

    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
    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.
  • Ramin K at Jan 17, 2013 at 11:23 pm

    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.
  • Jakov Sosic at Jan 19, 2013 at 6:11 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 17, '13 at 10:14p
activeJan 19, '13 at 6:11p
posts4
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase