PUPPET SERVER OVERVIEW What is Puppet Server: Puppet is a configuration management framework with an object-oriented.

. It will allow you to write heavily reusable and understandable configuration definitions. It performs administrative tasks (such as adding users, installing packages, and updating server configurations) based on a centralized specification. In the Puppet view, a server is a collection of resource objects that have a set of particular attributes that describe how that object looks. It is your job to build a catalog of resource declarations that will tell Puppet how those resources should look when properly configured.
Puppet has been developed to help the sysadmin community move to building and sharing mature tools that avoid the duplication of everyone solving the same problem. It does so in two ways: 1. It provides a powerful framework to simplify the majority of the technical tasks that sysadmins need to perform 2. The sysadmin work is written as code in Puppets custom language which is shareable just like any other code.

Puppet Server Language:

Puppet consists of a custom declarative language to describe system configuration, which can be either applied directly on the system, or compiled into a catalog and distributed to the target system via clientserver paradigm (using a REST API), and the agent uses system specific providers to enforce the resource specified in the manifests. The resource abstraction layer enables administrators to describe the configuration in high-level terms, such as users, services and packages without the need to specify OS specific commands (such as rpm, yum, apt).

Puppet Server Software:

Puppet Server generally comes with two packages

1. The Puppet package itself, which comes with Facter, and 2. The Puppet Master server. Puppet The first piece is the Puppet program itself. Its an executable Ruby program that has the majority of Puppets functionality rolled up and made accessible via the command line. With the Puppet program, you can syntax check your Puppet code, apply the resources to a machine manually, describe the current state of the world as seen by the abstraction layer, and get some documentation of Puppets workings.

Puppet Master
When we need to apply our Puppet configurations to a large number of servers, it becomes laborious to log in to each machine, copy our configurations to it, and execute the Puppet command against them. We are better served by keeping all of our configurations in a central location, defining which configurations apply to which servers, and then letting Puppet do the work of pulling the configurations from the repository and applying them. To enable this client-server behavior, Puppet has a network daemon called the Puppet Master.

The Puppet program can be run in a daemonized mode by the server init and is then referred to as a Puppet agent. The agents talk to the Puppet Master over clientcertificate authenticated SSL and the master hands out their configuration catalog. In its default configuration, the agents work in a polling mode and check in for catalog updates every 30 minutes. This allows us to store our configurations in a central location without having to worry about keeping all of our systems catalogs in sync through some out of-band means. Puppet Server System Components:
Puppet is typically (but not always) used in a client/server formation, with all of your clients talking to one or more central servers. Each client contacts the server periodically (every half hour, by default), downloads the latest configuration, and makes sure it is in sync with that configuration.

SVN OR ANYTHING

PUPPET MASTER

XML/RPC OVER HTTPS

CLIENT

CLIENT

CLIENT

Puppets functionality is built as a stack of separate layers, each responsible for a fixed aspect of the system, with tight controls on how information passes between layers:

Features of Puppet Server:

Idempotency One big difference between Puppet and most other tools is that Puppet configurations are idempotent, meaning they can safely be run multiple times. Once you develop your configuration, your machines will apply the configuration often by default, every 30 minutes and Puppet will only make any changes to the system if the system state does not match the configured state. Because of this, you can use Puppet to manage a machine throughout its lifecycle from initial installation, to ongoing upgrades, and finally to end-of-life, where you move services elsewhere. Cross Platform Puppets Resource Abstraction Layer (RAL) allows you to focus on the parts of the system you care about, ignoring implementation details like command names, arguments, and file formats your tools should treat all users the same, whether the user is stored in NetInfo or /etc/passwd. We call these system entities resources.
RESOURCE TYPES

The concept of each resource (like service, file, user, group, etc) is modelled as a type. Puppet decouples the definition from how that implementation is fulfilled on a particular operating system, for instance, a Linux user versus an OS X user can be talked about in the same way but are implemented differently inside of Puppet.
PROVIDERS

Providers are the fulfillment of a resource. For instance, for the package type, both yum and apt are valid ways to manage packages. Sometimes more than one provider will be available on a particular platform, though each platform always has a default provider. There are currently 17 providers for the package type.

Supported Platforms:
Puppet 2.6 and 2.7 can run on the following platforms:

Linux
Red Hat Enterprise Linux, version 4 and higher CentOS, version 4 and higher Scientific Linux, version 4 and higher Oracle Enterprise Linux, version 4 and higher Debian, version 5 (Lenny) and higher Ubuntu, version 8.04 LTS and higher Fedora, version 15 and higher SUSE Linux Enterprise Server, version 11 and higher Gentoo Linux Mandriva Corporate Server 4 ArchLinux

BSD
FreeBSD 4.7 and later OpenBSD 4.1 and later

Other UNIX
Mac OS X, version 10.4 (Tiger) and higher Solaris, version 10 and higher AIX, version 5.3 and higher HP-UX

Windows
Windows Server 2003 and 2008 (Puppet version 2.7.6 and higher) Puppet requires Ruby. Certain versions of Ruby work better with Puppet than others. Ruby 1.8.7 and 1.8.5 are fully supported with Puppet 2.6 and 2.7, and Puppet Labs runs automated tests on both of these versions. Ruby 1.9.2 and higher are supported with Puppet 2.7, and Puppet Labs runs automated tests on version 1.9.2. Ruby 1.8.1 is partially supported for agent-only use on a best-effort basis, and is not included in our automated testing.

Versions of Puppet Server and License:

0.25.5 ,0.25.4 ,0.25.3 ,0.25.2 ,0.25.1 ,0.25.0 ,0.24.9 ,0.24.8 ,0.24.7 ,0.24.6 ,0.24.5 ,0.24.4 ,0.24.3 ,0.24.2 ,0.24.1 ,0.24.0 (misspiggy) ,0.23.2 ,0.23.1 (beaker) ,0.23.0 ,0.22.3 ,0.22.2 (grover) ,0.22.1 (kermit) ,0.22.0 ,.0.20.0 2.6.13 ,2.6.12 ,2.6.11 ,2.6.10 ,2.6.9 ,2.6.8 ,2.6.7 ,2.6.6 ,2.6.5 ,2.6.4 ,2.6.3 ,2.6.2 ,2.6.1 ,2.6.0 2.7.10 Pulled due to regressions from 2.7.9 ,2.7.9 ,2.7.8 ,2.7.7 died in the Thunderdome ,2.7.6 ,2.7.5 ,2.7.4 ,2.7.3 ,2.7.2 died in the Thunderdome and was never released. ,2.7.1 ,2.7.0 (Statler) . NOTE:

What license is Puppet released under?

Puppet is open source and is released under the Apache 2.0 License.Versions prior to Puppet 2.7.0 and Facter 1.6.0 were released under the GPL version 2.0 license.

Features in 2.7.X Version:

Ruby 1.9 Support 2.7.0 is the first version of Puppet to support Ruby 1.9. Weve targeted 1.9.2 and higher versions. There are still a few known issues, but bugs are being aggresively fixed with Ruby 1.9 and its now a first-class citizen on our Continuous Integration system. Deterministic Catalog Application Previously, Puppet didnt guarantee the application of a catalog of unrelated resources in any particular order. This meant that if you forgot to specify some important `before` or `require` relationship, a single catalog might work fine on eight nodes and then fail mysteriously on the ninth and tenth. This could be frustrating! Now its gone: Puppet will make sure that the same catalog will always be applied in the same order on every machine, and itll either succeed reliably or fail reliably. (This change will also be appearing in the final 2.6.x releases.) Manage Network Devices Puppet has new types for managing network hardware, and a new `puppet device` subcommand for applying these configurations. These are in their early stages and can currently only handle Cisco IOS-based hardware, but theyre the start of a big leap forward in Puppets ability to manage your entire infrastructure. Look a blog with more details of this functionality soon.

How to Upgrade to New Versions:

The high level steps involved in a successful upgrade are: 1. Install the new version of Puppet on a separate Puppet Master. Youll usually want to spin up a new virtual machine for this purpose. 2. Copy all of your Manifests and Modules to the new Puppet Master. This isnt such a big deal with git or subversion. 3. Test and validate your existing Puppet Agent nodes against the new Puppet Master. This step is where things get a little messy. 4. Configure all of the existing nodes to cut over to the new Puppet Master after acceptance testing has passed. 5. Deploy the new version of the Puppet Agent on a select few testing nodes. Puppet makes this process quite pleasant. 6. Run through acceptance testing on these testing nodes. 7. When acceptable, cut the entire infrastructure over to the new version of the Puppet Agent. This process often takes a team of experienced engineers several weeks to complete. With great power comes great responsibility, and the entire configuration of your data center is potentially impacted by an upgrade of Puppet.

COMPARISON WITH OTHER RELATED OPEN SOURCE CM SOFTWARES

S/W NAME ARUSHA PROJECT BCFG2 CHEF FUSION INVENTORY WITH GLPI PUPPET

LANGUAGE PYTHON PYTHON RUBY PERL,PHP

LICENSED BSD BSD APACHE GPL

MUTUAL AUTH

ENCRYPTS YES YES YES YES

FIRST RELEASE 2001-07-21 2004-08-11 2009-01-15 2010

YES YES YES YES

LATEST STABLE VERSION 2005-04-19 2012-01-27 2010-08

RUBY

SMART FROG STAF

JAVA C++

APACHE FROM 2.7.0 AND PRIOR IS GPL LGPL CPL

YES

YES

2005-08-30

2011-1209(2.7.9)

YES NO

YES PARTIAL

2004-02-11 1998-02-16

2009-1-26 2011-03-31

PLATFORM SUPPORT: S/W ARUSHA PROJECT BCFG2 CHEF FUSION INVENTORY WITH GLPI PUPPET SMART FROG STAF AIX YES PARTIAL YES YES BSD YES YES YES YES HP-UX YES NO YES YES LINUX YES YES YES YES MAC OS NO PARTIAL YES YES SOLARIES YES YES YES YES WINDOWS NO NO YES YES OTHERS NO NO YES NO

YES NO YES

YES NO YES

YES YES YES

YES YES YES

YES YES YES

YES YES YES

YES YES YES

YES NO YES

Quick View about CM Tools Available:

Arusha Project (ARK) Manage package and configuration specification of hosts via a custom XML description language. Can be used as a front end for Cfengine or PIKT. Provides some collaboration features between administration 'teams'. The last commit dates from April 2007. Bcfg2 Software to manage the configuration of a large number of computers using a central configuration model and the clientserver paradigm. The system enables reconciliation between clients' state and the central configuration specification. Detailed reports provide a way to identify unmanaged configuration on hosts. Generators enable code or template based generation of configuration files from a central data repository.

FusionInventory with GLPI FusionInventory is a solution for hardware and software inventory with agent or agentless using SNMP (like for computer inventory or switch inventory), Wake On Lan (WOL), software deployment using the OCS Inventory NG protocol and peer-to-peer download, network connected devices (using NetBIOS, nmap and SNMP). It can be used with GLPI directly and other Asset solution (with lib server PHP integration). Chef Chef is a configuration management tool written in Ruby, and uses a pure Ruby DSL for writing configuration "recipes". These recipes are basically bundles of installation steps (or scripts) to be executed. Chef can be used as a clientserver tool, or used in "solo" mode. Puppet Puppet consists of a custom declarative language to describe system configuration, distributed using the clientserver paradigm (using XML-RPC protocol in older versions, with a recent switch to REST), and a library to realize the configuration. The resource abstraction layer enables administrators to describe the configuration in high-level terms, such as users, services and packages. Puppet will then ensure the server's state matches the description. There is support in Puppet for using a pure Ruby DSL as an alternative configuration language in version 2.6.0 and later. SmartFrog Java-based tool to deploy and configure applications distributed across multiple machines. There is no central server; you can deploy a .SF configuration file to any node and have it distributed to peer nodes according to the distribution information contained inside the deployment descriptor itself. STAF "The Software Testing Automation Framework (STAF) is an open source, multi-platform, multi-language framework designed around the idea of reusable components, called services (such as process invocation, resource management, logging, and monitoring)." [31] There are STAF plugins to perform a variety of common configuration management functions, such as distributed scheduling, execution, and file copying.
Installation of Puppet Server:

Puppet uses a basic client-server model to allow you to manage configuration across multiple machines. A central server runs a "puppetmasterd" that stores the configuration description and resource files for several server nodes. You can set up a single Puppetmaster instance and store configuration for a heterogeneous collection of servers. Puppetmaster servers need not run the same distribution or operating system as the components running the Puppet client.
For most operating systems, Puppet can be installed using the packages provided by your operating system, and this is the recommended method of using Puppet unless you need access to features that have been introduced in more recent versions. When upgrading Puppet always upgrade the Puppetmaster component on the centralized server before updating the Puppet client on the managed systems: older versions of the client can always communicate with newer versions of Puppetmaster, but the inverse is not guaranteed to be the case.

Install Puppetmaster
For Debian and Ubuntu systems, ensure that your system is up to date and install Puppetmaster by issuing issue the following commands:
apt-get update apt-get upgrade apt-get install puppetmaster rdoc

For CentOS systems, issue the following commands to install the EPEL repository, ensure the system is up to date and then install the Puppetmaster component:
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-54.noarch.rpm yum update yum install puppet-server

For Fedora systems, issue the following commands to ensure your system is up to date and then install the Puppetmaster component:
yum update yum install puppet-server

Remember that the Puppetmaster component must be of the same version or newer than the clients that connect to it. Before using the Puppetmaster node, you must ensure that the /etc/puppet/manifests/site.pp file exists, which you can accomplish with the following command:
touch /etc/puppet/manifests/site.pp

Install the Puppet Client

For Debian and Ubuntu systems, ensure that your system is up to date and then install the Puppet client by issuing issue the following commands:
apt-get update apt-get upgrade apt-get install puppet

For CentOS systems, issue the following commands to install the EPEL repository, ensure the system is up to date and then install the Puppet client:
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-54.noarch.rpm yum update yum install puppet

For Fedora systems, issue the following commands to ensure your system is up to date and then install the Puppet component:
yum update yum install puppet

A Puppet client can connect to a Puppetmaster component running on another operating system as long as the Puppet client is of the same version or older than the Puppetmaster server that it connects to.

Installing servers with Puppet

In the first part of the tutorial, we installed Puppet directly from the source. This is a great way to learn and experiment, but for production purposes we would like to use a standard package - in this case, an Ubuntu package we can install via apt-get. This way, you can ensure that the same version of Puppet is present on your servers and update it automatically if need be. The Ubuntu package also has a few bonus features that the source package doesnt. If you want to follow along with the tutorial using your existing Puppet source install, thats fine. Its a good idea to make sure youre using the same version of Puppet on both client and server, or you may run into obscure and annoying problems, so either install from the same source package on your client machine, or set up two fresh machines with the Ubuntu package as described below.
# add-apt-repository ppa:mathiaz/puppet-backports # apt-get update # apt-get install puppet puppetmaster

You can now start the Puppetmaster daemon and make the service persistent:
# update-rc.d puppetmaster defaults # puppet master mkusers NOTE:

If there is a firewall between the Puppetmaster and its clients (eg an iptables firewall on the Puppetmaster server itself) you will need to open TCP port 8140 to the clients.

HOWTO Install Puppet on CentOS 5.0

Puppet installation procedure on CentOS 5.0

Installing a Puppet Server

1. Setup dlutters yum repository: download the repository file
cd /etc/yum.repos.d wget http://people.redhat.com/dlutter/yum/dlutter.repo

Enable the proper repository, edit the dlutter.repo file, find the [dlutterrhel5] section and set enabled=1 2. Install puppet server
yum install puppet-server

3. (Optional) If you want help commands to show useful stuff install the rubyrdoc package
yum install ruby-rdoc

4. Create a minimal manifest file in /etc/puppet/manifests with the following content:

# The name of the system running the file server

$server = "pmaster" node default { }

(where pmaster is the name of your puppet server) 5. Start the puppet server
/etc/init.d/puppetmaster start

6. Enable server startup on boot

chkconfig puppetmaster on

Installing a Puppet Client

1. Setup dlutters yum repository (see details in the server setup). 2. Install puppet client
yum install puppet

3. (Optional) If you want help commands to show useful stuff install the rubyrdoc package
yum install ruby-rdoc

4. (From this point on the steps should also be carried out on the server to enable it own built-in client) Configure the puppet client to connect to the server, edit the file /etc/sysconfig/puppet, uncomment the PUPPET_SERVER line, specify the servers address 5. Setup puppet client certificate (since were using SSL here you need to make sure the client can properly resolve its own and the servers FQDN, note that you do not need to setup a certificate on the server) Run the puppet client daemon once to generate a certificate request to the server:
/etc/init.d/puppet once -v

Sign the certificate request on the server

puppetca --sign puppet01

(where puppet01 is the FQDN of your client host, you can see pending requests with puppetca list) Run the client again to retrieve the certificate
/etc/init.d/puppet once -v

6. Test the client

/etc/init.d/puppet once -v

7. (Optional) if you want the client to automatically pull configuration from the server every 30 minutes, enable it in chkconfig and start it as a service

CONFIGURING PUPPET SERVER : Open Firewall Ports On Server and Agent Node In order for the puppet master server to centrally manage agent nodes, you may need to open port 8140 for incoming tcp connections on the puppet master. Consult your firewall documentation for more details. Configuration Files The main configuration file for Puppet is /etc/puppet/puppet.conf. A package based installation file will have created this file automatically. Unlisted settings have reasonable defaults. To see all the possible values, you may run:

$ puppet genconfig Create Your Site Manifest Puppet is a declarative system, so it does not make much sense to speak of executing Puppet programs or scripts. Instead, we choose to use the word manifest to describe our Puppet code, and we speak of applying those manifests to the managed systems. Thus, a manifest is a text document written in the Puppet language and meant to describe and result in a desired configuration. Puppet assumes that you will have one central manifest capable of configuring an entire site, which we call the site manifest. You could have multiple, separate site manifests if you wanted, though if doing this each of them would need their own puppet servers. Individual system differences can be seperated out, node by node, in the site manifest. Puppet will start with /etc/puppet/manifests/site.pp as the primary manifest, so create /etc/puppet/manifests and add your manifest, along with any files it includes, to that directory. It is highly recommended that you use some form of version control (git, svn, etc) to keep track of changes to manifests.