Puppet users - Dec 2010 - Best practices for different hosts with different configs

Greetings,
I''m just getting started with setting up Puppet in an environment of
about ~15 servers, a mixture of Mac OS X servers and Ubuntu servers -
each with different roles and obviously different versions of configs.

Before I get too carried away, I was hoping to get advice on the "rule
of thumb" about different versions of configs.  Most of the
documentation and examples I''ve seen seem to be geared more towards
"roles" of a set of nodes, such as "http nodes, dns nodes"
etc.  What
hasn''t been too clear to me is a smaller scale environment where there
aren''t multiple nodes sharing the same job.

Say I have an application installed on two of my servers and
obviously, each server has its own version of the config files for
that.  What is the "best practice" to manage that?  Do I define a
class for "server1" with each thing I want to manage, and point to a
specific file (e.g. puppet://puppet/files/server1/config.cfg  .../
server2/config.cfg ...etc)?

Any nudge in the right direction is greatly appreciated!  Thanks.

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

The way we manage is by using multiple File paths right now , for example 

	file { "/usr/local/bin/portstats.pl":
		ensure => present,
		owner  => root,
		group  => root,
		mode   => 755,
		source => ["puppet:///cacti/$project/portstats.pl.$hostname",
                          
"puppet:///cacti/$project/portstats.pl-$class",
			   "puppet:///cacti/$project/portstats.pl",
			   "puppet:///cacti/portstats.pl.$hostname",
			   "puppet:///cacti/portstats.pl",
			  ]
	}


so you can use $project + $class variable in your manifest defining nodes . 

Best is to use templates , if you can easily differentiate between configs and
they don''t differ much .

Or you could use peinaar''s external Data lookup ,
http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php  to make
sense out of your nodes structure and filenames .



Thanks  , 
~saurabh verma 

On 13-Dec-2010, at 9:30 AM, Josh wrote:
> Greetings,
> I''m just getting started with setting up Puppet in an environment
of
> about ~15 servers, a mixture of Mac OS X servers and Ubuntu servers -
> each with different roles and obviously different versions of configs.
> 
> Before I get too carried away, I was hoping to get advice on the "rule
> of thumb" about different versions of configs.  Most of the
> documentation and examples I''ve seen seem to be geared more
towards
> "roles" of a set of nodes, such as "http nodes, dns
nodes" etc.  What
> hasn''t been too clear to me is a smaller scale environment where
there
> aren''t multiple nodes sharing the same job.
> 
> Say I have an application installed on two of my servers and
> obviously, each server has its own version of the config files for
> that.  What is the "best practice" to manage that?  Do I define a
> class for "server1" with each thing I want to manage, and point
to a
> specific file (e.g. puppet://puppet/files/server1/config.cfg  .../
> server2/config.cfg ...etc)?
> 
> Any nudge in the right direction is greatly appreciated!  Thanks.
> 
> -- 
> 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.
> 
-- 
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 13/12/10 04:00, Josh wrote:
> Greetings,
> I''m just getting started with setting up Puppet in an environment
of
> about ~15 servers, a mixture of Mac OS X servers and Ubuntu servers -
> each with different roles and obviously different versions of configs.
>
> Before I get too carried away, I was hoping to get advice on the "rule
> of thumb" about different versions of configs.  Most of the
> documentation and examples I''ve seen seem to be geared more
towards
> "roles" of a set of nodes, such as "http nodes, dns
nodes" etc.  What
> hasn''t been too clear to me is a smaller scale environment where
there
> aren''t multiple nodes sharing the same job.
>
> Say I have an application installed on two of my servers and
> obviously, each server has its own version of the config files for
> that.  What is the "best practice" to manage that?  Do I define a
> class for "server1" with each thing I want to manage, and point
to a
> specific file (e.g. puppet://puppet/files/server1/config.cfg  .../
> server2/config.cfg ...etc)?
>
> Any nudge in the right direction is greatly appreciated!  Thanks.
You can use a variable in the source path definition. e.g.
puppet:///files/$host/config.cfg.

The source parameter can also take an array and will search each path in
order until it gets a positive hit:
source => [
  "puppet:///files/$host/config.cfg",
  "puppet:///modules/mymodule/config.cfg",
]

See source section of
http://docs.puppetlabs.com/references/latest/type.html#file for more
details.

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

Daniel Piddock wrote:
> You can use a variable in the source path definition. e.g.
> puppet:///files/$host/config.cfg.
Though, using puppet:///module/files/config.cfg.$hostname as the source 
means it can sit inside the module, so all your configs can be in a 
single class in a single module. I find this much simpler to manage, 
personally.

Cheers,
Avi

-- 
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 Dec 12, 2010, at 8:00 PM, Josh wrote:
> Greetings,
> I''m just getting started with setting up Puppet in an environment
of
> about ~15 servers, a mixture of Mac OS X servers and Ubuntu servers -
> each with different roles and obviously different versions of configs.
> 
> Before I get too carried away, I was hoping to get advice on the "rule
> of thumb" about different versions of configs.  Most of the
> documentation and examples I''ve seen seem to be geared more
towards
> "roles" of a set of nodes, such as "http nodes, dns
nodes" etc.  What
> hasn''t been too clear to me is a smaller scale environment where
there
> aren''t multiple nodes sharing the same job.
> 
> Say I have an application installed on two of my servers and
> obviously, each server has its own version of the config files for
> that.
I find that in this case either:
1) You can template the config file to reuse it.
or
2) You define each as a diffierent role so one might be puppetmaster::slave and
the other might be puppetmaster::ca.  (In my config both serve configuration. 
Ca is the CA and holds the reports)

Obviously, depending on what you''re doing, this might not be true.
> What is the "best practice" to manage that?  Do I define a
> class for "server1" with each thing I want to manage, and point
to a
> specific file (e.g. puppet://puppet/files/server1/config.cfg  .../
> server2/config.cfg ...etc)?
> 
> Any nudge in the right direction is greatly appreciated!  Thanks.
I''ve found 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.