Puppet uses a client-server paradigm. Clients (also called agents) are installed on all the systems to be managed; the server(s) (also called the Master) is installed on a central machine(s) from where we control the whole infrastructure.
We can find Puppet's packages on the most recent OS, either in the default repositories on in the additional ones (for example, EPEL for Red Hat derivatives).
The client package is generally called puppet, so the installation is a matter of typing something like the following:
apt-get install puppet # On Debian derivatives
yum install puppet # On Red Hat derivatives
To install the server components, we can run the following command:
apt-get install puppetmaster # On Debian derivatives
yum install puppet-server # On RedHat derivatives
Note
To have updated packages for the latest versions, we should use Puppet Labs' repositories: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html.
To install Puppet on other operating systems, check http://docs.puppetlabs.com/guides/installation.html.
Both agents (clients) and the Master (server) use the configuration file /etc/puppet/puppet.conf, which is divided in [sections] and has an INI-like format. All the parameters present in the configuration file may be overridden while invoking puppet from the command line. All of them have default values; here is a sample with some of the most important ones:
[main]
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
[agent]
server = puppetcertname = $fqdn # Here, by default, is the node's fqdn
runinterval = 30[master]
autosign = false
manifest = /etc/puppet/manifests/site.pp
modulepath = /etc/puppet/modules:/usr/share/puppet/modulesA very useful command to see all the current configuration settings is as follows:
puppet config print all
With the previous information, we have all that we need to understand the main files and directories that we deal with when we work with Puppet:
Logs are in
/var/log/puppet(but also on normal syslog files, with the facility daemon), both for agents and Master.The Puppet operational data is in
/var/lib/puppet.SSL certificates are stored in
/var/lib/puppet/ssl. By default, the agent tries to contact a Master hostname calledpuppet, so either name our serverpuppet.$domainor provide the correct name in theserverparameter.When the agent communicates with the Master, it presents itself with its
certname(this is also the hostname placed in its SSL certificates). By default, thecertnameis the fully qualified domain name (FQDN) of the agent's system.By default, the agent runs as a daemon that connects to the Master every
30minutes and fetches its configuration (the catalog, to be precise).On the Master, we have to sign each client's certificates request (manually). If we can cope with the relevant security concerns, we may automatically sign them (
autosign = true).The first
manifestfile (that contains Puppet DSL code) that the Master parses when a client connects, in order to produce the configuration to apply to it, is/etc/puppet/manifests/site.pp. This is important as all our code starts from here.Puppet modules are searched for and automatically loaded from the directories
/etc/puppet/modulesand/usr/share/puppet/moduleson the Master.
Note
Puppet Enterprise is provided with custom packages that reproduce the full stack, Ruby included, and uses different directories.
/etc/puppetlabs/puppet/ is the main configuration directory; here, we find puppet.conf and other configuration files. The other directories are configured by default with these paths:
vardir = /var/opt/lib/pe-puppet
logdir = /var/log/pe-puppet
rundir = /var/run/pe-puppet
modulepath = /etc/puppetlabs/puppet/modules:/opt/puppet/share/puppet/modulesIn this book, we will mostly refer to the open source version; besides, the previous paths, all the principles, and usage patterns are the same.