puppet overview - pros and cons

[David Lutterkort]

On Sat, 2006-12-23 at 03:25 +0100, Axel Thimm wrote:
> Thanks for the puppet overview. Maybe we should create a wiki page
> with a product/feature matrix?
> 
> On Fri, Dec 22, 2006 at 04:17:45PM -0800, David Lutterkort wrote:
> 
> > PROS
> > ----
> 
> 
> >               * Override mechanism for classes to allow for simple
> >                 one-off (or hundred-off) tweaks, e.g. to take webserver
> >                 class from above but use with different httpd.conf
> 
> That's nice.

One thing I forgot to mention: puppet lets you also express dependencies
between config elements, so that you can say that the httpd package
should be installed/upgraded first before your custom httpd.conf is
copied from the central server. A similar mechanism also lets you say
that service X should be restarted whenever puppet needs to make a
change to file Y (useful to keep service restarts to the absolute
minimum needed)

> >       * Tie-in with kickstart: provision basic system with ks (including
> >         puppet client), complete config with puppet [4]
> 
> That, of course, defeats lots of the security items, but there is no
> otherway. One just needs to be aware of that.

Yeah, it's not entirely watertight, but the holes that it leaves are
fairly esoteric (somebody posing as a client while you are installing
the client; somebody posing as the server while you are installing a
client), and you'll discover both breaches quickly (when the client you
are installing gets to the point where it asks the server for a cert;
the request will either fail or never show up on your server)

> What about diffing support, e.g. compare what's there and what we'd
> like it to become, kind of a dry-run session to check deviations
> between spec and reality?

Both the command-line tool and the client daemon have a 'noop' option,
that goes through the motions w/o making changes. After changes to
configs, I usually test them by running
        # /usr/sbin/puppetd -v --onetime --noop
which produces output like
        notice: Starting configuration run
        notice: //common/lemon/autofs-server/configfile[/etc/sysconfig/autofs]/file=/etc/sysconfig/autofs/source: is {md5}6cd456ce35b212ea429e63bf892d2535, should be {md5}3ed0678eb6af27c0a264522705e79a08 (noop)
        notice: //common/lemon/autofs-server/configfile[/etc/auto.homes]/file=/etc/auto.homes/owner: is build, should be root (noop)
        notice: //common/lemon/users/user=build/home: is /home/build, should be /homes/build (noop)
        notice: Finished configuration run in 4.56 seconds

The lines are telling me that
      * /etc/sysconfig/autofs has different content from what it should
        be
      * /etc/auto.homes has the wrong owner
      * the user 'build' has the wrong home directory
Of course, puppet would fix all these if I ran that without --noop

David