Centralized Ubuntu Management With Puppet

Centralized server management can be achieved on our Ubuntu Server with products such as the long established Puppet project. The puppet server is rather aptly names the Puppet Master and this acts as a central configuration server that can be used to keep configuration files maintained across your server estate and ensure services are installed and running. In this tutorial we will install the PuppetMaster on an Ubuntu 12.04 server and have the Puppet Agents, also on Ubuntu poll the master for their settings which will be to maintain a running version of Apache. Apache will be automatically installed and kept running by the puppet agent.

Puppet is an open source framework based on Ruby for managing the configuration of computer system. Puppet is licensed under GPLv2 and can be used as a standalone or client-server model. We will use client-server in this tutorial. To see information relating to the puppet master package:

apt-cache show puppetmaster

The default configuration of the clients or puppet agents will look for the puppet server or puppet master as the host puppet or puppet.yourdomain.com. it is therefore easiest to ensure that the host that will act as the puppet master be configured with DNS or hosts entries as puppet. In the example the puppet master will be configured on the host 192.168.0.200 so the clients will have host file entries:

192.168.0.200     puppet

The lab does not use DNS.

 

The central puppet server is known as the puppetmaster and should be the host with the entry puppet in the hosts file or DNS. To install the puppetmaster package

apt-get update
apt-get install puppetmaster

 

The puppet client software is from the puppet package. This is installed on the hosts that you would to be managed by the puppet master

apt-get update
apt-get install puppet

In the simplest for we need to create a manifest file on the puppet master. Puppet manifests describe what should be maintained on the client and use a .pp prefix. We need to create the file /etc/puppet/manifests/site.pp

package {
 'apache2':
   ensure => installed
}
service {
 'apache2':
  ensure => true,
  enable => true,
  require => Package['apache2']
}

As we have not described any nodes, this entire file this will be effective for all puppet agents that have been trusted by the server. The wording is self-explanatory; we are ensuring the package apache2 is installed and the service exists and is enabled and we put a requirement on the service that is comes from the apache2 package.

Simply we will not need to install apache on the client machines, puppet will manage that and ensure the service is kept running.

In the demonstration we will install the package puppet onto two machines. The first, web1, we will run puppet manually before starting the service. As root:

puppetd --test

This will start the puppet client and connect to the host, puppet. The client will present a certificate request to the puppetmaster. To ensure only known and authorized clients are serviced not action will take place until the certificate is signed by the puppet master.

From the console of the puppet master we need to check for the signing requests with

puppetca --list

We can sign the request with

puppetca --sig web1

Returning to the web1 puppet agent we can manually run the puppet client again; remember we did not start the service just ran the client:

puppetd --test

We now see the configuration applying and apache2 will be installed and started. The client will not run again though until we run it ourselves; so we really do need the client service. We can configure it to auto-start using the file, /etc/default/puppet. Edit the line so it reads

START=yes

Now start the client:

/etc/init.d/puppet start

The client will now run every 30 minutes to poll the puppet master. If you need a different polling interval this can be configured on the desired puppet agent: /etc/puppet/puppet.conf where xxx is the desired interval in minutes

[main]
 runinterval=xxx

There is no need at all for us to start the agent ourselves with puppetd, even if the certificate is as yet unsigned. On our second machine, web2, we will directly configure the auto-start of puppet and start the service. We will sign the request on the server and leave the client to poll again. Once this has been effected apache2 will be installed and running on the second client

As a simple demonstration we have seen how puppet can be used as a central configuration server to puppet clients. We have only used Ubuntu here; however puppet has cross platform support.