Puppet users - Feb 2012 - Researching Puppet - Local host variations

Hello everyone,

First-time poster investigating Puppet for managing CentOS-based
firewall distros at various locations. I have approximately 130
machines to administrate so some type of config management is
certainly needed.

I''ve been working through Puppet tutorials and I''m wondering
if Puppet
will do what I need; all machines are very similar. However each
machine will have small differences. For example,

1. SSH Ports: Machines have custom SSH ports so that''s one variable
that would prevent me from just copying sshd_config.

2. Squid ACLs: All machines will have certain Squid ACLs, but many
machines will vary otherwise, say in cache size for example.

3. Iptables: All machines have standardized Iptables rules in /etc/
rc.d/rc.firewall.local. But again each machine has rules on a per-host
basis.

Originally, what I thought I could do is have certain sections of the
config files managed by Puppet, with other sections managed by local
edits on a per-host basis. But I''m gathering that''s not how
Puppet
works - you manage the whole config file and apply various config
versions based on Facter facts, node types, etc. If that''s my only
option, I''ll have to maintain custom conf files on Puppetmaster for
every host!

I''m open to advice generally, and comments specifically on how to
manage small per-host variations. Create custom Facter conditionals
for hosts?

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.

On Feb 7, 6:17 am, thinkwell <thinkwelldesi...@gmail.com>
wrote:
> Hello everyone,
>
> 2. Squid ACLs: All machines will have certain Squid ACLs, but many
> machines will vary otherwise, say in cache size for example.
In regards to #2 on your list it''s pretty easy to do stuff like this
if you''re running a relatively recent version of Squid.
include /etc/squid/conf.d/*

Then let Puppet add config files as needed based on regex of the
hostnames or lookups in a data store.
/etc/squid/conf.d/general.acl.config
/etc/squid/conf.d/reverseproxy.acl.config
/etc/squid/conf.d/memory.config

You can template your config files based on facts about the system. I
wrote a custom fact, memorysize_raw, which is a bit easier to work
with than the standard memorysize and can decide how much memory to
give a daemon based on local system memory.

<% if memorysize_raw.to_i >= 1500000000 then -%>
  cache_mem 8500 MB
<% elsif memorysize_raw.to_i >= 7000000000 then -%>
  cache_mem 2500 MB
< % else -%>
  cache_mem 128 MB
<% end -%>

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 Feb 7, 8:17 am, thinkwell <thinkwelldesi...@gmail.com>
wrote:
> Hello everyone,
>
> First-time poster investigating Puppet for managing CentOS-based
> firewall distros at various locations. I have approximately 130
> machines to administrate so some type of config management is
> certainly needed.
>
> I''ve been working through Puppet tutorials and I''m
wondering if Puppet
> will do what I need; all machines are very similar. However each
> machine will have small differences. For example,
>
> 1. SSH Ports: Machines have custom SSH ports so that''s one
variable
> that would prevent me from just copying sshd_config.
>
> 2. Squid ACLs: All machines will have certain Squid ACLs, but many
> machines will vary otherwise, say in cache size for example.
>
> 3. Iptables: All machines have standardized Iptables rules in /etc/
> rc.d/rc.firewall.local. But again each machine has rules on a per-host
> basis.
>
> Originally, what I thought I could do is have certain sections of the
> config files managed by Puppet, with other sections managed by local
> edits on a per-host basis. But I''m gathering that''s not
how Puppet
> works - you manage the whole config file and apply various config
> versions based on Facter facts, node types, etc. If that''s my only
> option, I''ll have to maintain custom conf files on Puppetmaster
for
> every host!
>
> I''m open to advice generally, and comments specifically on how to
> manage small per-host variations. Create custom Facter conditionals
> for hosts?

The kind of work you describe is well within Puppet''s capabilities.
In particular, Puppet supports defining file contents via ERB
templates.  That allows you to write the common parts of files exactly
as normal (all in one place), and to interpolate the custom parts from
Puppet variables.  And that''s just to start.


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 Tue, Feb 7, 2012 at 06:17, thinkwell <thinkwelldesigns@gmail.com>
wrote:
> First-time poster investigating Puppet for managing CentOS-based
> firewall distros at various locations. I have approximately 130
> machines to administrate so some type of config management is
> certainly needed.
>
> I''ve been working through Puppet tutorials and I''m
wondering if Puppet
> will do what I need; all machines are very similar. However each
> machine will have small differences. For example,
>
> 1. SSH Ports: Machines have custom SSH ports so that''s one
variable
> that would prevent me from just copying sshd_config.
[...]
> 3. Iptables: All machines have standardized Iptables rules in /etc/
> rc.d/rc.firewall.local. But again each machine has rules on a per-host
> basis.
>
> Originally, what I thought I could do is have certain sections of the
> config files managed by Puppet, with other sections managed by local
> edits on a per-host basis. But I''m gathering that''s not
how Puppet
> works - you manage the whole config file and apply various config
> versions based on Facter facts, node types, etc. If that''s my only
> option, I''ll have to maintain custom conf files on Puppetmaster
for
> every host!
If every host is unique, you already maintain custom files for every
host, right?  The only difference in the Puppet model is that you can
*see* the them in one place, so you are aware of just how much work it
is making that work the way you want.

However, you can do other things.  You can use facts to make decisions
based on the "nature" of the machine, as you would with the cache size
for Squid.

You can use a parameterized class or a template, and set the "SSH
port" on a per machine basis as data, then use the same configuration
template for every node.  That moves from "a whole file" to "the
specific data we need to be unique", which is much easier to reason
about in the long term.

Finally, you can use things like `file {
"/etc/rc.d/rc.firewall.local": source =>
"puppet:///modules/firewall/rc.firewall.${fqdn}"  }` to use a per-host
fact to select which configuration file you want.  File even supports
multiple "sources", and selecting the first one, so you can have it
look for a "per host", then "per class", then
"default" firewall
configuration.

Ultimately, though, you are *seeing* the problem you already had, just
laid out in a way that calls attention to it.

-- 
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
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 Feb 8, 12:39 pm, Daniel Pittman <dan...@puppetlabs.com>
wrote:
> Ultimately, though, you are *seeing* the problem you already had, just
> laid out in a way that calls attention to it.

+1

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

I''m getting this worked through in my head, I think. I wanted to make
sure that Puppet would totally support me if the migration is made.
I''ve concluded that I can standardize a bit more than I have, and with
Daniel''s suggestion, quoted below, I''m well impressed! :

file {
"/etc/rc.d/rc.firewall.local": source =>
"puppet:///modules/firewall/rc.firewall.${fqdn}"  }

That''s just perfect - allows very granular "per machine"
edits that''ll
streamline workflow 100%. Thanks for the comments everyone! :-)

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