This is our second post in our “Introduction to Puppet tutorial” We already covered “What is a puppet” and other ad-hoc posts on Puppet earlier. In this post, we will try to understand basic terminology used in Puppet which will help us understand Puppet

Puppet master

This is our Puppet server which takes care of puppet clients which connect to it. It serves required data to clients and gets reports from clients once our configurations are done on them. This acts as a centralized machine for all your Puppet activity by default.

Masterless Puppet

Puppet configuration management tool can be deployed in two ways. One is Client-server model and the other is an independent node model or a masterless setup. Depends on your requirement we can use one of these models. Many people may have a question how is it possible to configure Masterless-puppet. For those people, “puppet apply /path/to/my/site.pp” command is the answer. We can apply puppet catalogs if we have puppet manifests locally available using puppet apply command. We will see more about this command in future.


Running state of Puppet server is called as puppetmasterd

Puppet Agent

Running state of Puppet client software. This software is useful for

1)  Gathering facts: Getting vast system details like OS type, version, RAM details, CPU details and much             more using installed facter tool.

2)  Send those details to master for getting required compiled configuration details(catalogs)

3) Getting compiled configuration details from puppet master

4) Executing those compiled configurations at a designated time.

5) Collecting and sending reports of this expected configuration on the client.

Puppet Node

Puppet clients are called as nodes.


These are files/configs which can be used for changing settings at nodes.


Reporting tool at nodes, which reports about OS/HW/SW types etc to puppet master about the node where it is installed.

Clipped output of facter command:

architecture => amd64
blockdevices => sda,sdb
boardmanufacturer => Hewlett-Packard
fqdn => linuxnix
gid => root
hardwareisa => x86_64
hostname => linuxnix
id => root
interfaces => eth0,lo,virbr0,virbr0_nic,wlan0
ipaddress =>
kernel => Linux
kernelmajversion => 4.4
kernelrelease => 4.4.0-31-generic
kernelversion => 4.4.0
memoryfree => 2.41 GB
memorysize => 7.58 GB
memorysize_mb => 7757.53


Attributes are used to specify the state desired for a given configuration resource. We will see more about this in our coming posts.

Puppet Manifests

A file containing code written in the Puppet DSL language, and named with the .pp file extension. All manifests are stored in /etc/puppet/manifests or /etc/puppet/modules/<name-of-module>/manifests.


Compiled form of manifests.

Puppet Modules

Modules are a bigger form of manifests. Every manifest in a module should define a single class or defined type.


Physical files you can serve out to your agents through puppet. These are stored in /etc/puppet/files or /etc/puppet/modules/<name-of-module>/files.


Template files contain puppet code with variables which can populate variable values depending on node details.


Collections of resources


Composite collections of resources

Complete list at In our next post we will see how to install Puppet and configuring it with basic settings in Debian/Redhat based machines.

The following two tabs change content below.
Mr Surendra Anne is from Vijayawada, Andhra Pradesh, India. He is a Linux/Open source supporter who believes in Hard work, A down to earth person, Likes to share knowledge with others, Loves dogs, Likes photography. He works as Devops Engineer with Taggle systems, an IOT automatic water metering company, Sydney . You can contact him at surendra (@) linuxnix dot com.