Wednesday, March 7, 2012

Centralized Management with Puppet


Introduction

Puppet is a configuration automation tool that allows you to centralize management of the various Linux flavors running on your network. Puppet supports central management of the important aspects of your systems, such as: files, packages, users, services, cron, mounts, etc.

This is a step by step tutorial on how to install the Puppet Server (puppetmaster) on one machine, and the Puppet Client (puppetd) on another. We then perform a simple test to make sure Puppet is working properly.

Background

This installation is performed on CentOS 5.5 Server, but should work for most Linux flavors with slight modifications.

During this tutorial we’ll be using linuxhowto.in as our domain name. The server will be given the hostname “puppetserver” and IP 192.168.1.1. The client hostname is “puppetclient” with IP 192.168.1.2.

Network Requirements 

If DNS isn’t set up on your network, verify the hosts files on both server and client include entries for both machines. For this scenario the following entries would be added to /etc/hosts. Use your favorite text editor to add lines reflecting your own network settings similar to the lines below.
192.168.1.1 puppetserver.linuxhowto.in puppetserver
192.168.1.2 puppetclient.linuxhowto.in puppetclient

The server runs on port 8140. Make sure there’s no firewall blocking port 8140 between the two machines.

Yum Setup 

Many of the packages we need are in the EPEL repository.

puppetserver:# rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

Client Install

Install Puppet only
puppetclient:# yum install puppet

Server Installation 

# yum install *puppet*

Starting puppet configuration management tool master server
Manifest /etc/puppet/manifests/site.pp must exist [fail]

Starting the Puppetmaster

Puppet comes in two parts: a server (the Puppetmaster) which listens for connections from clients and then tells them what manifest they should have, and a client program, which runs on each machine under Puppet control and connects to the Puppetmaster to get its manifest.
In this example, we’re running the master and client on the same machine, so let’s start the server:
# puppet master --mkusers

Running the Puppet client

With the Puppetmaster running, we can now check that everything is working as it should by running the client:
# puppet agent --test --server=`hostname`
info: Caching catalog for localhost.localdomain
info: Applying configuration version '1256130640'
notice: Finished catalog run in 1.23 seconds

Creating Puppet classes

While technically we have just applied a Puppet manifest to the machine, it’s not a very interesting one, as it does nothing at all. Let’s create a manifest that manages a simple service: NTP (the Network Time Protocol). NTP is a daemon which keeps the machine’s clock synchronised with reference servers on the Internet.
First we’re going to create a class for the NTP service (if you haven’t done any object-oriented programming, a class is just a named chunk of code which we can refer to).
I’ve created a (nearly) empty template for you for the NTP class, so go ahead and edit the file /etc/puppet/modules/ntp/manifests/ntp.pp. Currently it looks like this:

class ntp {
}
Change it to this:

class ntp {
 
    package { "ntp": 
        ensure => installed 
    }
 
    service { "ntp":
        ensure => running,
    }
}
And save the file. We’ve now created a Puppet manifest which will manage the NTP daemon (ntp).

Creating Puppet nodes

Because Puppet can manage many machines at once, we still need to tell it to apply the NTP manifest to this machine. To do that, edit the file /etc/puppet/manifests/nodes.pp. You’ll see a template that looks like this:

node myserver {
}
Change it to this:
node myserver {
    include ntp
}

(Replace myserver with the name of your machine - that is, the output of hostname -s.)
When Puppet runs, it looks for a node definition that matches the name of the client machine, and applies all the classes that it finds listed there with include.
You’ve now told Puppet that the server myserver (or whatever your machine is named) should have the NTP manifest applied to it.

Applying changes with Puppet

When you run Puppet again:
# puppet agent --test --server=`hostname`
info: Caching catalog for localhost.localdomain
info: Applying configuration version '1256130643'
notice: //ntp/Service[ntp]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.94 seconds
What happened here? Puppet looked up the manifest for myserver and found this:

    package { "ntp": 
        ensure => installed 
    }
 
    service { "ntp":
        ensure => running,
    }
This says that the package ntp should be installed, and the service ntp should be running. Your system may or may not have ntp already installed, but if not, Puppet will install it. Puppet checks to see if the service is started, and if it’s not, it starts the service for you. If you run Puppet again now:

# puppet agent --test --server=`hostname`
info: Caching catalog for localhost.localdomain
info: Applying configuration version '1256130643'
notice: Finished catalog run in 0.66 seconds
you’ll see that Puppet does nothing, because the manifest is satisfied.

Puppet manifests are declarations


Puppet manifests are not a set of instructions, in the way that a shell script or a Ruby program is. They’re a declaration of how the world should be (or that part of it under Puppet’s control, anyway). If reality differs from the manifest, Puppet takes steps to adjust reality.
This means that Puppet isn’t just useful for building machines. It can also check them regularly to make sure that nothing important has changed, and if it has, to correct it. If you stop the NTP service manually and then run Puppet again, you’ll find Puppet restarts it.
Conversely, if you decide you no longer want NTP running on your machines, you can change the word running to stopped, and Puppet will enforce this policy on every machine that includes the NTP manifest (which could be hundreds or even thousands of servers).

Now we will look Howto Setup puppet to control Multiple machines


In the above tutorial we created a file /etc/puppet/manifests/nodes.pp, which lists the nodes (machines) that Puppet knows about, and what configuration they should have. Currently it looks like this:
 
node myserver {
    include ntp
}
As we’re adding a new node to the system, we need to modify the file so that it reads like this:
 
node myserver {
    include ntp
}
 
node myclient {
    include ntp
}

Authorising a client

Puppet uses SSL (Secure Sockets Layer), an encrypted protocol, to communicate between master and clients. This means that only a client with a correctly signed SSL certificate can access the Puppetmaster and receive its configuration. To exchange certificates between the master and client, follow this procedure.

Configuring the client to contact the server

Edit your /etc/puppet/puppet.conf file to tell the client where to find the Puppetmaster:

server = puppetserver.linuxhowto.in

Generate a certificate request

On the client, run:

# puppet agent --test
info: Creating a new certificate request for puppetclient.linuxhowto.in
info: Creating a new SSL key at /etc/puppet/ssl/private_keys/puppetclient.linuxhowto.in.pem
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate
notice: Set to run 'one time'; exiting with no certificate

Sign the certificate

On the master:

# puppetca -l
puppetclient.linuxhowto.in
There is a certificate request pending for myclient. To sign it, run:

# puppetca -s puppetclient.linuxhowto.in
notice: Signed certificate request for puppetclient.linuxhowto.in
notice: Removing file Puppet::SSL::CertificateRequest puppetclient.linuxhowto.in
 at 
  '/var/lib/puppet/ssl/ca/requests/puppetclient.linuxhowto.in.pem'
If there is no certificate request listed, the client was not able to contact the server for some reason. Check that you have the right server address set in puppet.conf on the client, and that TCP port 8140 is open on both the master and client firewalls. The puppet master daemon also needs to be running on the master.

Run Puppet for the first time

On the client, you should now be able to run:

# puppet agent --test
notice: Got signed certificate
info: Caching catalog at /var/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //ntp/Service[ntp]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.92 seconds
Just as on the server in the first part of the tutorial, Puppet is now applying the ntp class to puppetclient. At the moment all this class does is ensure the ntp service is running, but of course it could do many more interesting things.



Congratulations, testing is complete and you have a working Puppet setup. Puppetd by default will automatically poll the server every 30 minutes.


DISCLAIMER: The information provided on this website comes without warranty of any kind and is distributed AS IS. Every effort has been made to provide the information as accurate as possible, but no warranty or fitness is implied. The information may be incomplete, may contain errors or may have become out of date. The use of this information described herein is your responsibility, and to use it in your own environments do so at your own risk.


                Copyright © 2012 LINUXHOWTO.IN

1 comment: