Puppet

Introduction

Links

http://reductivelabs.com/trac/puppet/wiki/StyleGuide
http://reductivelabs.com/trac/puppet/wiki/GlossaryOfTerms
http://reductivelabs.com/trac/puppet/wiki/PuppetIntroduction
http://reductivelabs.com/trac/puppet/wiki/DocumentationStart
http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial

Puppet-daemons:

• Client: puppetd (call with -t and -d option to see what it does)
• Server: puppetmasterd

Puppet installation

• see RD-Computefarm-Checklist before starting
• Puppet-Server: puppet.klu.infineon.com (this is a alias that points to kluls231.klu.infineon.com)
• Puppet-rpms:
  • puppet-server-0.23.2-1.el4 (Server package)
  • puppet-0.23.2-1.el4 (client package)
• The client rpm automatically tries to contact the server with the name puppet.<local-domain>

Puppet configuration

Configuration directories and files

(Stored in svn,http://svn.klu.infineon.com/repos/AdminToolKit/trunk/puppet ):

• /etc/puppet:
  • facts (fact definiton, e.g. sitename, which can be used in the rules afterwards)
  • manifests (definitions and rules,...)
  • ssl
  • fileserver.conf (defining where files are served from and to whom)
• /var/lib/puppet: (place where the puppet-files are stored)
  • <site> (Site specific files, place defined in fileserver.conf)
    • <site>/push
    • <site>/static

Some configuration files with short describtion

To get a feeling for the language:

/etc/puppet/manifests/site.pp (read by the puppetmaster to find out what do to for the site)

#import custom facts
file { $factdir: source => "puppet://$servername/facts", recurse => true }

# import the functions
import "functions.pp"

# import site defenitions
import "sitedef.pp"

# import all of the server classes
import "classes/*"

# Common settings
import "common.pp"

#  vim: set syntax=puppet

/etc/puppet/fileserver.conf:

# This file consists of arbitrarily named sections/modules
# defining where files are served from and to whom

# Define a section 'files'
# Adapt the allow/deny settings to your needs. Order
# for allow/deny does not matter, allow always takes precedence
# over deny

[klu]
path /var/lib/puppet/files/klu     # Files specially for the klu site
allow *.klu.infineon.com           # only machines in KLU see them

[kia]                              # same for the other sites
...
[facts]                            # place for the fact definitions
path /etc/puppet/facts
allow *.infineon.com

/etc/puppet/facts (example fact definiton)

# returns site name to facter
# ohad.levy@infineon.com
# Solaris returns the LDAP domain instead of DNS domain
Facter.add("sitename") do
        setcode do
                %x{hostname | cut -c 1-3}.chomp
        end
end

Useful links

Autogenerate puppet pp files.

http://cft.et.redhat.com/

Notes

1. 1 Configuration Language.

Puppet script.

1. 2 Transaction Layer.

Puppet can run multiple time resulting in the same status of handled files. 
Your machines will apply the configuration often (by default, every 30 minutes)
Puppet will only make any changes to the system if the system state does not match the configured state.

1. 3 Resource Abstraction Layer.

Puppet takes care of operating system specific command names. You should only care about configuration. Configuration entries are called resourses. 

--noop no-op, or dry-run

• providers.

makes it possible to use resouce types like file, user, and package.

• Modifying the system.

Taking a couple of lines onto the end of your fstab, you use the mount type to create a new resource that knows how to modify the fstab, or NetInfo, or wherever mount information is kept.

All resources are simple collections of attributes, some of which change how the resource functions and some of which directly manage the resource (these are called properties).

There is another special kind of attribute, those which work on all resources. These are called metaparams, and include things like the log level for the resource or --noop.

• Exec Resources

Sometimes, there will not be a resource type already developed for managing the resource you're interested in; for these cases, we provide an exec resource type, which allows you to run external commands, along with hooks to make the exec behave idempotently. For instance, you can create an exec instance that creates a Subversion repository using the svnadmin command, along with a check that causes the command to only get run if the repository does not already exist

• Classes

The next step up is to start associating resources; you would normally have at least the sudo package installed, and you'd put both the package and the configuration file into a class: Then you can just call include sudo and both resources would get applied

• Inheritance

Puppet supports a limited form of class inheritance, but it's only useful for one thing: Subclasses can override resources defined in parent classes, using a special override syntax

In the sub class above, the resource type (in this case File) is capitalized. This means that we are referring to a type that has already been declared. Using file instead would be illegal since that would result in resource overlap.

• Facter Variables

$operatingsystem variable. This variable is set, along with many others, in the top-level scope by the parser, which gets the values from Facter -- you can get a list of all available variables by just running the stand-alone facter script, but you'll also want to know about $ipaddress and $hostname, just to start.

• Selectors

Another new thing is the ? { ... } syntax, which we call a selector and is somewhat similar to the relatively common trinary operator. This tests the variable before the ?, and picks a matching value from the provided list, or the default value if nothing matches. This allows us to provide different values based on the operating system, host name, or just about anything else we want. Note that it is a parse error if no value matches. Also, selectors (as of 0.22.2) are case-insensitive in their matching.

• resource reference

The File[sshd_config] syntax is called a resource reference, and it's used to uniquely refer to a resource.

• Variables

$myvar = value Puppet will refuse to allow you to assign to the same variable twice in a given class or definition, because it will only ever use the second value and your first value will get thrown away, since all variable assignments are evaluated before any resource specifications.