DevOps with Puppet: Tips on Setting it up for Configuring Servers

DevOps with Puppet: Tips on Setting it up for Configuring Servers

Today I will describe briefly how Puppet works, as well as basic configuration and installation of the server and two clients.


Puppet is an open-source configuration management tool that is used for software update and configuration on client servers. With Puppet, going to the servers and updating them manually will no longer be needed, as all you’ll have to do is monitor if the servers are operating correctly.

How we apply Puppet

So, let’s begin. We have 3 servers with OS installed. We’re typically using CentOS 6.5.

Installing the server:

Hostname «puppets1»


Connect the repository and update the system. If the repository is outdated, it will update

Set up the puppet server

Configuration files are called manifests. They can be found in the directory /etc/puppet/manifests


Standard Manifest – site.pp. Puppet searches for it in the first place.

The basic element of the manifest is a resource. A resource is a file, cron task, package, or user service.


Let’s make changes to the file /etc/puppet/manifests/site.pp

This resource launches verification of the /etc/passwd file owner, and if it differs from the root, Puppet sets the root user as the owner of the file. The same occurs with the group and permissions.


(node) is the most important element in the configuration file. In a nutshell, it’s the type of the machine where puppet configuration will be deployed.


Here’s an example of NGINX manifest for node server{n} Nginx.pp:

Run puppetmaster:

Installing and configuring the Puppet client

Hostname «puppet c1»


Set up the repository:

Set up the puppet client:

Run the command on the client:

Add the node on the server:

Check if our puppet works on the client:

Info: Retrieving pluginfacts

Info: Retrieving plugin

Info: Caching catalog for

Info: Applying configuration version ‘1404892414’

Notice: /Stage[main]/Main/File[/etc/passwd]/mode: mode changed ‘0777’ to ‘0644’

Notice: Finished catalog run in 6.15 seconds

Next, let’s edit the site.pp on the server:

On the client, run the command:

Info: Retrieving pluginfacts

Info: Retrieving plugin

Info: Caching catalog for

Info: Applying configuration version ‘1404892414’

Notice: /Stage[main]/Nmap/Package[nmap]/ensure: created

Notice: /Stage[main]/Nginx/Package[nginx]/ensure: created

Notice: /Stage[main]/Nginx/Service[nginx]/ensure: ensure changed ‘stopped’ to ‘running’

Info: /Stage[main]/Nginx/Service[nginx]: Unscheduling refresh on Service[nginx] Notice: Finished catalog run in 34.49 seconds

Jul 09 12:47:53 Installed: 2:nmap-5.51-3.el6.x86_64

Jul 09 12:48:07 Installed: nginx-1.0.15-5.el6.x86_64


As we can see, we have two packages set up on the client that we have registered in site.pp.


Now, let’s add a couple of lines in the config file so that we don’t have to run puppet manually:

Run puppet:

By default, there is a check with the master every 30 minutes.

Writing manifests and classes

On the server, edit manifests/site.pp

classes directory – for the location of classes files

nodes directory – for settings files of our server clients

$emailaddress – set the values to send reports by email


Class basic-class.pp: 


For basic settings, we need the latest version of the mailx package, which we indicate by ensure => latest
We also make changes to the motd file for the salutation after a successful login to the system. Puppet already has in its arsenal such variables as: 


${Fqdn} – Fully Qualified Domain Name of your host

${Operatingsystem} – Defines the version of your operating system. In my case, it’s CentOS

${Operatingsystemrelease} – Defines the version of your operating system. At the moment of finishing this article, I had a version 6.6 system installed.


The next class software-class.pp is required for installation and removal of the needed and not needed packages:

$Removepackeges – lists the packages for removal

$Installpackeges – lists the packages to be installed


Now let’s view the ssh-config-class.pp class

In this class, we will:



– Install openssh-server in the package section

– Keep running sshd service that requires an installed openssh-server package

– Copy 3 files from the /files/ssh directory with settings for our ssh server



Now, let’s see the crontab-class.pp class

In this class, we:


– Set up cronnie if it wasn’t set up yet somehow  

– Download and copy the file from the file/puppetagent directory to /opt/bin/scripts directory on our client

– Specify which user will have our script running and when. Also, add the PATH and MAILTO values for cron


Now let’s proceed with the setup of the manifests for our servers. Create nodes/hardnodes.pp file

Here we have indicated:



* For all servers with the hostname puppetc {1,2,3,4,5 ……} the above-described classes will be applied.


That’s all for now. Stay tuned, I will have more tips for you soon!


Add comment

E-mail is already registered on the site. Please use the Login form or enter another.

You entered an incorrect username or password

Sorry that something went wrong, repeat again!
Contact us