Introduction to Puppet

In Unix World is often said that a good system administrator tends to automate every activity that has to be repeated more than one times.
This is typically done with shell scripts and custom gluing of available tools, but of course is not the best solution for large infrastructures with distributed sysadmin force.
Different Linux distributions or Unix dialects feature various custom tools to administer systems, sometimes these tools provide automation facilities and management of a large number of servers.
Puppet is a systems management and configuration  tool that can be used to manage and automate system administration on a variety of *nix servers (currently have been reported successful installations on RedHat/Centos/Debian/Suse/Gentoo Linux and Solaris, Darwin and FreeBSD).
In the Open Source there are few alternatives as Cfengine, Bcfg2 and Chef (this one is a recent derivation of Puppet)  and among the commercial products you can somehow relate Puppet to Bladelogic or OpsWare Server Automation System (now HP) (unlike Puppet they can manage also Windows servers and network equipment, at a considerable cost and with questionable efficiency).

Puppet key features are:
- managing of typical administration items (packages, services, users, cron jobs, configuration files...) on different systems using a unique generic, platform independent language.
- highly scalable client/server architecture: you can manage from one to thousands servers
- recreation of the same system based on puppet language is a repeatable and predictable activity
- Written in Ruby, Puppet is Open Source, can be easily enhanced and adapted to custom needs
- modular architecture permits user's enhancements
- logic and content of file items distribution can be based on local automatic server "facts"

Elements
On client machines you can just install the client package (yum install puppet, apt-get install puppet), the package provides a service /etc/init.d/puppetd that works on the configuration file, usually /etc/puppet/puppet.conf ( on versions of puppet pre 0.24.x there were different configuration files according to roles: /etc/puppet/puppetd.conf,  /etc/puppet/puppetmasterd.conf ...).
The puppetd service by default, polls every 30 minutes the server configured in /etc/puppet/puppet.conf ( with a line like: server=10.42.0.10 ) or automatically looks for an host named puppet (you obtain the same result with a line like: "10.42.0.10 puppet" in /etc/hosts ): if it finds a configuration set defined for the local node, it pulls and applies it.
Puppetd requires also the package facter, which provides a customizable tool (facter indeed) that collects local information (hostname, mac addresses, operating system and so on) that can be used as variables in puppet configurations.

On the server system (which can be client of itself) you have to install the puppet-server package. This provides the /etc/init.d/puppetmasterd service which listens to port TCP 8140 and uses the same /etc/puppet/puppet.conf  as configuration file.
On the puppet server you can begin to start your puppet configurations (written in "manifests" files) editing the file /etc/puppet/manifests/site.pp (or what is configured as manifest= /path/to/first/manifest/file in /etc/puppet.conf ).
From this file you can import other manifests where you can describe the whole puppet configuration for your infrastructure.
Communication between client and server is secured by SSL x509 cryptographic certificates. By default the puppetmaster is also the CA that signs server and client's certificates.

Privacy Policy