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
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:
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 called puppet, so either name our server puppet.$domain or provide the correct name in the server parameter.
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.
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).
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 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.
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: