Puppet users - Jun 2010 - FYI: Mac Configuration Management at the Los Alamos National Laboratory white paper

Here''s a white paper you may be interested in.

The Los Alamos National Laboratory (LANL) had a need for central configuration
management of non-Windows computers. LANL has three to five thousand Macs and an
equal number of Linux based systems. The primary goal was to be able to
inventory all non-windows systems and patch Mac OS X systems. LANL examined a
number of commercial and open source solutions and ultimately selected Puppet.

This paper will discuss why we chose Puppet, how we implemented it, and some
lessons we learned along the way.


http://www.afp548.com/filemgmt/index.php?id=108&comments=1

---
Thanks,

Allan Marcus
505-667-5666



-- 
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 Fri, Jun 4, 2010 at 4:59 PM, Marcus, Allan B <allan@lanl.gov> wrote:
> Here''s a white paper you may be interested in.
>
> The Los Alamos National Laboratory (LANL) had a need for central
> configuration management of non-Windows computers. LANL has three to five
> thousand Macs and an equal number of Linux based systems. The primary goal
> was to be able to inventory all non-windows systems and patch Mac OS X
> systems. LANL examined a number of commercial and open source solutions and
> ultimately selected Puppet.
>
> This paper will discuss why we chose Puppet, how we implemented it, and
> some lessons we learned along the way.
>
>
> http://www.afp548.com/filemgmt/index.php?id=108&comments=1


nice working getting this out Allan. Reading now...

-- 
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 agree with Nigel - and thank you again for sending this out.  I''ve
been
following your implementation closely since last June, and have implemented
a version of your puppetd.sh script.  It''s interesting to see the
changes
you''ve made and the lessons learned.  Again, excellent job on the
documentation - it solves some questions/changes I had planned this summer.

-Gary

On Fri, Jun 4, 2010 at 8:40 PM, Nigel Kersten <nigelk@google.com> wrote:
>
>
> On Fri, Jun 4, 2010 at 4:59 PM, Marcus, Allan B <allan@lanl.gov>
wrote:
>
>> Here''s a white paper you may be interested in.
>>
>> The Los Alamos National Laboratory (LANL) had a need for central
>> configuration management of non-Windows computers. LANL has three to
five
>> thousand Macs and an equal number of Linux based systems. The primary
goal
>> was to be able to inventory all non-windows systems and patch Mac OS X
>> systems. LANL examined a number of commercial and open source solutions
and
>> ultimately selected Puppet.
>>
>> This paper will discuss why we chose Puppet, how we implemented it, and
>> some lessons we learned along the way.
>>
>>
>> http://www.afp548.com/filemgmt/index.php?id=108&comments=1
>
>
>
> nice working getting this out Allan. Reading now...
>
>  --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>


-- 
Gary Larizza

Director of Technology
Huron City Schools
http://www.huronhs.com

悟

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

Thanks for the white paper it was very helpful.  A few questions
though, if you can answer it.  With the large client base how are you
setting up your puppet master(s) to hand the workload?

eg.  1 puppetmaster running passenger with apache?
       physical12 GB memory, 4 CPUs ?
       careful module management?

The main reason I ask is that I am looking to setup a puppet
infrastructure that needs to support 3000 + clients.  Currently have
about 37 running against my puppet master with no issues and working
on the design I am going to deploy.

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.

----- "Allan B Marcus" <allan@lanl.gov> a écrit :

| Here''s a white paper you may be interested in.
| 
| The Los Alamos National Laboratory (LANL) had a need for central
| configuration management of non-Windows computers. LANL has three to
| five thousand Macs and an equal number of Linux based systems. The
| primary goal was to be able to inventory all non-windows systems and
| patch Mac OS X systems. LANL examined a number of commercial and open
| source solutions and ultimately selected Puppet.
| 
| This paper will discuss why we chose Puppet, how we implemented it,
| and some lessons we learned along the way.
| 
| 
| http://www.afp548.com/filemgmt/index.php?id=108&comments=1
| 
| ---
| Thanks,
| 
| Allan Marcus
| 505-667-5666

Nice paper, thanks for sharing !

Nico.

-- 
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 Sat, Jun 5, 2010 at 5:36 AM, Chuck <csschwe@gmail.com> wrote:
> Thanks for the white paper it was very helpful.  A few questions
> though, if you can answer it.  With the large client base how are you
> setting up your puppet master(s) to hand the workload?
>
> eg.  1 puppetmaster running passenger with apache?
>       physical12 GB memory, 4 CPUs ?
>       careful module management?
>
> The main reason I ask is that I am looking to setup a puppet
> infrastructure that needs to support 3000 + clients.  Currently have
> about 37 running against my puppet master with no issues and working
> on the design I am going to deploy.
>
You need to give us an idea as to how often these clients are running, and a
rough idea of your config payload, does it consist of lots of files?
templates? recursive file copies?

What puppetmaster architecture are you using at the moment? Webrick?
Mongrel? Passenger?

>
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
nigel

-- 
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 am currently using passenger and puppet 0.25.5 on RHEL 5.4

I am looking to support 3000 - 4000 nodes in the up coming years.
  2000 nodes in one data center
  500 nodes in each of three more data centers (1500 nodes)

The first use of puppet will be to allow us to fully provision a RHEL
server.  We are planning on using RPM packages via YUM to install most
files.   Configuration files / changes will be managed via puppet.
Right now about 70% static files and 30% templates.  There are not
currently any recursive file copies.

We have about 20 modules for configuring servers for our first
application area that is going to make use of puppet.  We expect this
to get quite a bit larger over the next year.  I also expect to
develop another 10 - 20 modules for base operating system
configuration.

I am currently worried about scalability as the number of modules and
clients on my puppet server increases.  I am planning on locating at
least one puppet server in each of the 4 data centers.

I am not finding any information on what to expect and to design into
my infrastructure as it matures so I don''t run into any unexpected
surprises.  It sounds like some people are using puppet in large
environments and I would like to know what the issues that have been
run into and if there is a way to design the environment to avoid
these issues.  I have been reading through the puppet mailing lists,
wiki, and documentation which has gotten me to my current use of
apache/passenger.

-- 
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 Jun 5, 2010, at 2:31 PM, Chuck wrote:
> I am currently worried about scalability as the number of modules and
> clients on my puppet server increases.  I am planning on locating at
> least one puppet server in each of the 4 data centers.
I''ve found that very bad things 
> I am not finding any information on what to expect and to design into
> my infrastructure as it matures so I don''t run into any unexpected
> surprises.  It sounds like some people are using puppet in large
> environments and I would like to know what the issues that have been
> run into and if there is a way to design the environment to avoid
> these issues.  I have been reading through the puppet mailing lists,
> wiki, and documentation which has gotten me to my current use of
> apache/passenger.
I''m not exactly sure what you want, but here''s some general
scaling advice:

If you are using storeconfigs, take a look at
http://www.masterzen.fr/2009/03/18/omg-storedconfigs-killed-my-database/

You probably want to use the "splay" option.  Normally it
won''t help much, but it will help make sure that the puppet clients
don''t all get "in sync" and all try to connect to the server
at once.

I''ve heard that using RubyEE or JRuby can help reduce the amount of ram
you need.

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

Hello,

----- "Patrick" <kc7zzv@gmail.com> a écrit :
| On Jun 5, 2010, at 2:31 PM, Chuck wrote:
| 
| > I am currently worried about scalability as the number of modules
| and
| > clients on my puppet server increases.  I am planning on locating
| at
| > least one puppet server in each of the 4 data centers.
| 
| I''ve found that very bad things 

Why ? I know some people here do it, with some real success. Having your master
near your clients is, to me, a good thing. Use a central master to configure
satellite ones. The only problem is about SSL chaining that can drive you crazy
:p

| > I am not finding any information on what to expect and to design
| into
| > my infrastructure as it matures so I don''t run into any
unexpected
| > surprises.  It sounds like some people are using puppet in large
| > environments and I would like to know what the issues that have
| been
| > run into and if there is a way to design the environment to avoid
| > these issues.  I have been reading through the puppet mailing
| lists,
| > wiki, and documentation which has gotten me to my current use of
| > apache/passenger.
| 
| I''m not exactly sure what you want, but here''s some general
scaling
| advice:
| 
| If you are using storeconfigs, take a look at
| http://www.masterzen.fr/2009/03/18/omg-storedconfigs-killed-my-database/
| 
| You probably want to use the "splay" option.  Normally it
won''t help
| much, but it will help make sure that the puppet clients don''t all
get
| "in sync" and all try to connect to the server at once.
| 
| I''ve heard that using RubyEE or JRuby can help reduce the amount of
| ram you need.

There''s a queue daemon now, you should take a look at this

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

First off, we don''t have reporting on. I can see how using reporting
can be useful, but it can also be a heavy load on a server. We do use Store
Config.

Our server is a Mac Xserve. 2 x 4 core Xeon processors. 8GB of RAM. We have no
load issues with about 1300 clients checking in hourly. That said, our
configurations aren''t very complicated.

Some obvious ways to split the load between servers are to use a different
server for MySQL and/or use a different server for file distribution.

Hope this helps.

---
Thanks,

Allan Marcus
505-667-5666



On Jun 5, 2010, at 6:36 AM, Chuck wrote:
> Thanks for the white paper it was very helpful.  A few questions
> though, if you can answer it.  With the large client base how are you
> setting up your puppet master(s) to hand the workload?
> 
> eg.  1 puppetmaster running passenger with apache?
>       physical12 GB memory, 4 CPUs ?
>       careful module management?
> 
> The main reason I ask is that I am looking to setup a puppet
> infrastructure that needs to support 3000 + clients.  Currently have
> about 37 running against my puppet master with no issues and working
> on the design I am going to deploy.
> 
> 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.

You mention how you''re looking into External Nodes - how do you
currently
decide which machines receive which configuration?

We had previously done this through hostnames (where each a portion of the
hostname was a class that was to be applied to the node), but I''m
looking to
move away from hostname-based certnames and toward a static ID (like you
mention in your paper).  Doing this would break our external node classifier
script - so I''m debating my next step while collecting information from
others.

Thanks!

On Sun, Jun 6, 2010 at 4:26 AM, Nicolas Szalay <nszalay@qualigaz.com>
wrote:
> Hello,
>
> ----- "Patrick" <kc7zzv@gmail.com> a écrit :
> | On Jun 5, 2010, at 2:31 PM, Chuck wrote:
> |
> | > I am currently worried about scalability as the number of modules
> | and
> | > clients on my puppet server increases.  I am planning on locating
> | at
> | > least one puppet server in each of the 4 data centers.
> |
> | I''ve found that very bad things
>
> Why ? I know some people here do it, with some real success. Having your
> master near your clients is, to me, a good thing. Use a central master to
> configure satellite ones. The only problem is about SSL chaining that can
> drive you crazy :p
>
> | > I am not finding any information on what to expect and to design
> | into
> | > my infrastructure as it matures so I don''t run into any
unexpected
> | > surprises.  It sounds like some people are using puppet in large
> | > environments and I would like to know what the issues that have
> | been
> | > run into and if there is a way to design the environment to avoid
> | > these issues.  I have been reading through the puppet mailing
> | lists,
> | > wiki, and documentation which has gotten me to my current use of
> | > apache/passenger.
> |
> | I''m not exactly sure what you want, but here''s some
general scaling
> | advice:
> |
> | If you are using storeconfigs, take a look at
> | http://www.masterzen.fr/2009/03/18/omg-storedconfigs-killed-my-database/
> |
> | You probably want to use the "splay" option.  Normally it
won''t help
> | much, but it will help make sure that the puppet clients don''t
all get
> | "in sync" and all try to connect to the server at once.
> |
> | I''ve heard that using RubyEE or JRuby can help reduce the amount
of
> | ram you need.
>
> There''s a queue daemon now, you should take a look at this
>
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
Gary Larizza

Director of Technology
Huron City Schools
http://www.huronhs.com

悟

-- 
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 Jun 5, 2:31 pm, Chuck <cssc...@gmail.com>
wrote:
> I am currently using passenger and puppet 0.25.5 on RHEL 5.4
>
> I am looking to support 3000 - 4000 nodes in the up coming years.
>   2000 nodes in one data center
>   500 nodes in each of three more data centers (1500 nodes)
> I am currently worried about scalability as the number of modules and
> clients on my puppet server increases.  I am planning on locating at
> least one puppet server in each of the 4 data centers.
Chuck,

Performance wise 500 clients should easily by served from a single 4
core 4Gb server. From my rough performance tests each one of those
servers should be able to service ~1500+ clients. With regards to
client catalog complexity my quoted numbers are with 50 classes & 300
resources per client, using storeconfigs.

-- 
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, Jun 8, 2010 at 9:51 PM, Marcus, Allan B <allan@lanl.gov> wrote:
> First off, we don''t have reporting on. I can see how using
reporting can be
> useful, but it can also be a heavy load on a server. We do use Store
Config.
>
> Our server is a Mac Xserve. 2 x 4 core Xeon processors. 8GB of RAM. We have
> no load issues with about 1300 clients checking in hourly. That said, our
> configurations aren''t very complicated.
>
> Some obvious ways to split the load between servers are to use a different
> server for MySQL and/or use a different server for file distribution.
>
Why not scale up to another puppetmaster? you may chose to run the other
puppet servers without CA functioanility, this will allow you to off load it
do many things (e.g. file requests, manifest compilation, reporting etc).

on a side note, Foreman can run on any machine (doesn''t really require
to
run on your puppetmaster), if you want to enable reports, there is a tiny
overhead of forwarding the reports to your foreman host (which could be
avoided too if you have another puppetmaster acting as your report server).

my 2 cents,
Ohad
>
> Hope this helps.
>
> ---
> Thanks,
>
> Allan Marcus
> 505-667-5666
>
>
>
> On Jun 5, 2010, at 6:36 AM, Chuck wrote:
>
> > Thanks for the white paper it was very helpful.  A few questions
> > though, if you can answer it.  With the large client base how are you
> > setting up your puppet master(s) to hand the workload?
> >
> > eg.  1 puppetmaster running passenger with apache?
> >       physical12 GB memory, 4 CPUs ?
> >       careful module management?
> >
> > The main reason I ask is that I am looking to setup a puppet
> > infrastructure that needs to support 3000 + clients.  Currently have
> > about 37 running against my puppet master with no issues and working
> > on the design I am going to deploy.
> >
> > 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<puppet-users%2Bunsubscribe@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<puppet-users%2Bunsubscribe@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.

I went to download this and it returned a 404. Is it still available somewhere?

-- cwebber

On Jun 4, 2010, at 4:59 PM, Marcus, Allan B wrote:
> Here''s a white paper you may be interested in.
> 
> The Los Alamos National Laboratory (LANL) had a need for central
configuration management of non-Windows computers. LANL has three to five
thousand Macs and an equal number of Linux based systems. The primary goal was
to be able to inventory all non-windows systems and patch Mac OS X systems. LANL
examined a number of commercial and open source solutions and ultimately
selected Puppet.
> 
> This paper will discuss why we chose Puppet, how we implemented it, and
some lessons we learned along the way.
> 
> 
> http://www.afp548.com/filemgmt/index.php?id=108&comments=1
> 
> ---
> Thanks,
> 
> Allan Marcus
> 505-667-5666
> 
> 
> 
> -- 
> 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.

You can find it here: http://is.gd/cOYhE

Cheers--

Charles

On Mon, Jun 14, 2010 at 10:43 AM, Christopher Webber
<kgbbelmont@gmail.com>wrote:
> I went to download this and it returned a 404. Is it still available
> somewhere?
>
> -- cwebber
>
> On Jun 4, 2010, at 4:59 PM, Marcus, Allan B wrote:
>
> > Here''s a white paper you may be interested in.
> >
> > The Los Alamos National Laboratory (LANL) had a need for central
> configuration management of non-Windows computers. LANL has three to five
> thousand Macs and an equal number of Linux based systems. The primary goal
> was to be able to inventory all non-windows systems and patch Mac OS X
> systems. LANL examined a number of commercial and open source solutions and
> ultimately selected Puppet.
> >
> > This paper will discuss why we chose Puppet, how we implemented it,
and
> some lessons we learned along the way.
> >
> >
> > http://www.afp548.com/filemgmt/index.php?id=108&comments=1
> >
> > ---
> > Thanks,
> >
> > Allan Marcus
> > 505-667-5666
> >
> >
> >
> > --
> > 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<puppet-users%2Bunsubscribe@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<puppet-users%2Bunsubscribe@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.