Installation and configuration

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/modules

A 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:

1. Logs are in /var/log/puppet (but also on normal syslog files, with the facility daemon), both for agents and Master.
2. The Puppet operational data is in /var/lib/puppet.
3. SSL certificates are stored in /var/lib/puppet/ssl. By default, the agent tries to contact a Master hostname called puppet, so either name our server puppet.$domain or provide the correct name in the server parameter.
4. 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, the certname is the fully qualified domain name (FQDN) of the agent's system.
5. By default, the agent runs as a daemon that connects to the Master every 30 minutes and fetches its configuration (the catalog, to be precise).
6. 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).
7. The first manifest file (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.
8. Puppet modules are searched for and automatically loaded from the directories /etc/puppet/modules and /usr/share/puppet/modules on 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/modules

In this book, we will mostly refer to the open source version; besides, the previous paths, all the principles, and usage patterns are the same.