[sf-perl] lack of perl in config management - problem?

Earl Ruby earl at ruby.org
Fri Dec 16 11:18:17 PST 2011

When my company first started building servers en masse about 8 years
ago we knew we needed a configuration management tool and looked at
what open source tools were available at that time. At that time none
met our needs, so we ended up writing our own, mostly in Perl with
some bash.

Our goals were:

* We wanted to be able to easily integrate new configuration scripts
into the framework.
* We wanted to be able to stage changes on staging/QA servers and then
move them into production.
* We wanted a class hierarchy, so that we could assign a server to
multiple classes (e.g. "base", "base-sanfrancisco", "apache-server",
* Each class can override configurations in the parent class, so
"apache-server" would build a base Apache server, and "admin-tools"
would install web-based administration tools, some of which might
override the settings in the apache-server class.
* Each host can also have host-specific settings which override the
base classes, so if you need to tweak settings on just one host you
* We wanted to be easily able to tell what configuration had been
applied to any host, and to keep all of the configurations in one
place. If you want to understand why something is set up in a certain
way on a host, it's easy to find the configuration and see what script
made which changes.
* We wanted to be able to lock down specific versions of an OS, its
patch set, CPAN tools, and our own packages, so that every server is
built using the exact same versions of all software packages.
* We wanted new servers to automatically plug themselves into our
Nagios monitoring system.
* We wanted to be able to take any server, reboot it, type 'inst-auto'
at the boot: prompt, and have it go from bare metal to
fully-configured without any additional manual intervention.

We built all that, but maintaining it takes time, and it's not our
core competency, so we looked at moving to Chef or Puppet. What we
found is that neither Chef nor Puppet implements classes the way we
have and neither one gives us the one-button build capability that we
wanted. Chef scales and scales, but is a huge undertaking to set up
and maintain. Puppet runs out of steam somewhere between 100 and 1000
servers, and is difficult to scale beyond that. Our system scales
infinitely, and it's dead-simple to set up an understand.

We looked at extending Chef or Puppet using the tools we'd written,
then realized that what we'd written was actually pretty damn good. We
are currently working to strip out the company-specific parts of the
framework, clean up the code, and release it as open source. We hope
that by doing so that other system engineers can extend it and add
capabilities that we would like to have but don't have time to add

We will probably be doing an initial release in about 3 months. I'd be
happy to do a demo for Perl Mongers when it's released.

On Sat, Dec 10, 2011 at 3:05 PM, Philip J. Hollenback <philiph at pobox.com> wrote:
> Something I'm thinking about - a lot of sysadmins these days are
> becoming programmers via their need to use config management.  The two
> big config management tools are Chef and Puppet.  Both are ruby-based.
> So you have lots of people coming to scripting for the first time, and
> they are using ruby.  Is that a problem?  Does this mean that a
> generation of sysadmins is coming of age _not_ using perl?
> I don't have any firm data on this, but it's my sense that a lack of
> config management tools based in perl is actively hurting the perl
> community.
> Oh and yes, I'm aware of Slaughter, but I don't think it is enough of a
> major player to count.  Also, it's not very actively maintained.
> Anyway, what do people think about this issue?  Has anyone analyzed it?
> Final question: perl is such a wonderful glue language - why isn't there
> a major config management tool based in perl?
> I'm hoping I'm wrong about all of this of course.
> P.
> --
> Philip J. Hollenback
> philiph at pobox.com
> www.hollenback.net
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

Earl Ruby

More information about the SanFrancisco-pm mailing list