From Newroco tech docs
Jump to: navigation, search



Puppet is an open-source next-generation server automation tool. It is composed of a declarative language for expressing system configuration, a client and server for distributing it, and a library for realizing the configuration

Online Tutorials

Puppet at OA

We have written puppet recipes to manage the following configurations:

  • Sudo, to match our password-less infrastructure
  • Pam, enabling a root account secured by securetty
  • Rsyslog
  • Collectd
  • NRPE (nagios remote procedure calls)
  • Mailx
  • User accounts & groups - including backuppc
  • SSH & SSHd
  • APT repositories (to use our local repository when available)
  • Locales
  • Vim (nice, simple default config)
  • DNS (resolv.conf, depending on what office the server is in))
  • NTP (depending on what office the server is in)
  • Apache - limiting requests to only coming from the reverse proxies
  • Postgresql & Mysql backups, when needed
  • Motd, although I've been too lazy to write them all :)
  • Some scripts used by nagios, like aacraid, or check_puppet

All the recipes are in /etc/puppet/manifests/classes/ .

Install a new client

On the client

If not already present, install the package puppet. The installation process will claim that puppet has "started" - although puppet only starts when it has a certificate signed by the server. The file /etc/puppet/puppet.conf needs to look something like this:

  1. <pre>
  2. [main]
  3. logdir=/var/log/puppet
  4. vardir=/var/lib/puppet
  5. ssldir=/var/lib/puppet/ssl
  6. rundir=/var/run/puppet
  7. factpath=$vardir/lib/facter
  8. pluginsync=true
  9. server=puppet.thehumanjourney.net
  10. certname=server.goo.thehumanjourney.net
  12. [puppetmasterd]
  13. templatedir=/var/lib/puppet/templates
  14. </pre>

Replace certname by the FQDN of the vm as defined in bind.

Allow Puppet to start by changing the "no" to a "yes" in /etc/default/puppet.

Restart puppet:

sudo /etc/init.d/puppet start

Puppet will see that it doesn't have a signed certificate yet, and will issue a certificate request to the server, and stop again.

On the server

sudo puppetca --list --all | grep hostname

Verify that the server you installed has issued a request.

Create a yourserver.pp file for the vm in /etc/puppet/manifests/nodes/ (use one of the other ones as model)

Sign the certificate:

  1. <pre>
  2. sudo puppetca --sign server.goo.thehumanjourney.net
  3. </pre>

You need to restart puppetmaster to get it notice the new config file you've added:

  1. <pre>
  2. sudo /etc/init.d/puppetmaster restart
  3. </pre>

Back on the client

Issue a test run:

sudo puppetd --test --debug

If it all works restart puppet:

sudo /etc/init.d/puppet restart



Install Puppet on your server with apt-get:

sudo apt-get install puppet puppetmaster

Building the Server

Puppet will look for your site manifest in /etc/puppet/manifests/site.pp, so create /etc/puppet/manifests and add your manifest, along with any files it includes, to that directory.

  • Sample Manifest

The site manifest can be as simple or as complicated as you want. A good starting point is to make sure that your sudoers file has the appropriate permissions:

  1. <pre>
  2. # site.pp
  3. file { "/etc/sudoers":
  4. owner => root, group => root, mode => 440
  5. }
  6. </pre>
  • Sample Node

We then want to create some nodes. Nodes represent the hosts you want to manage.

  1. <pre>
  2. #site.pp
  3. #'''create our first node'''
  4. node "webserver.reductivelabs.com" {
  5. include webserver, redhat
  6. }
  8. *create a default node
  9. node default {
  10. include base
  11. }
  12. </pre>
  • Add certname=$fqdn for puppetmasterd in /etc/puppet/puppet.conf
puppet:#vim /etc/puppet/puppet.conf
  • Sample /etc/puppet/puppet.conf (server)
  1. <pre>
  2. .
  3. .
  4. .
  5. .
  6. [puppetmasterd]
  7. templatedir=/var/lib/puppet/templates
  8. certname=puppet.thehumanjourney.net
  9. </pre>

Current OA configuration

Management actions

Class files define what actions the clients will take. Effectively these are scripts provided by the server to be run on the client. Clients get a mixture of group-wide class files and location specific examples.

Common class files are stored in /etc/puppet/manifests/classes/common/

Configuration for particular sites, including the SSN as distinct from the rest of OA South, is stored in /etc/puppet/manifests/classes/

Files are saved as function.pp, for example:

jreeves@puppet:~$ cat /etc/puppet/manifests/classes/oasouth_ssn/apache_oasouth_ssn.pp 
class apache_oasouth_ssn {
    file { "/etc/apache2/conf.d/access_control":
        	owner => "root",
        	group => "root",
        	mode  => 644,
		source => "puppet://puppet.thehumanjourney.net/dist/apps/apache_access_control_oasouth_ssn/access_control";

    exec { subscribe-accessrestriction:
       		command => "/usr/sbin/apache2ctl restart",
		logoutput => true,
		onlyif => "/bin/false",
		subscribe => FILE["/etc/apache2/conf.d/access_control"]


Note the source parameter - the location from which clients will download files from the server. The directory for this on the server is /var/lib/puppet/dist/

for example:

jreeves@puppet:~$ sudo cat /var/lib/puppet/dist/apps/apache_access_control_oasouth_ssn/access_control 
# This file is automatically maintained by Puppet
# Do not edit, your changes will be lost

<Directory / >
	Order Deny,Allow	
	Deny from all
	Allow from
	Allow from
	Allow from
	Allow from
	Allow from
	Allow from

Client management

Clients, or "nodes", are defined in /etc/puppet/manifests/nodes/

Each office or location has a subfolder containing details of specific hosts. There is also a pp file that holds common config for every office.

Note: In this configuration SSN hosts are in the oasouth directory. This is opposite to the above.

In /etc/puppet/manifests/nodes/oasouth.pp we see the oasouth base class defined:

class baseclass_oasouth {
        include baseclass
        include ntp_oasouth
        include dns_oasouth
        include apt_main_mirrored
        include apt_main_updates_mirrored
        include apt_main_security_mirrored
        include apt_universe
        include apt_universe_updates
        include apt_universe_security
        include nrpe_oasouth_ntp_time

We also see specific hosts defined:

# The finance server uses a tuned sudoers file
node ""{
     include ssh_config
     include apt_main_mirrored
     include apt_main_updates_mirrored
     include apt_main_security_mirrored
     include apt_universe
     include apt_universe_updates
     include apt_universe_security
     include check_packages
     include dns_oasouth
     include munin
     include admins_accounts
     include ntp_oasouth
     include vim
     include syslog
     include root_account
     include user_backuppc_oasouth
     include motd
     include nrpe
     include collectd
     include check_puppet
     include postgres_backup
     include nrpe_oasouth_ntp_time

Specific hosts are then defined (again? With overlap) in the appropriate sub directory:

jreeves@puppet:~$ cat /etc/puppet/manifests/nodes/oasouth/bitbol.pp
node "bitbol.goo.thehumanjourney.net" {
	include baseclass_oasouth
	include kvm_host