puppet 3.0.2 → 3.1.0.rc1

data/Gemfile

@@ -1,13 +1,10 @@
 source :rubygems
 
-# This is a fake version just to make bundler happy during development
-FAKE_VERSION = '9999.0.0'
-
 def location_for(place)
   if place =~ /^(git:[^#]*)#(.*)/
     [{ :git => $1, :branch => $2, :require => false }]
   elsif place =~ /^file:\/\/(.*)/
-    [FAKE_VERSION, { :path => File.expand_path($1), :require => false }]
+    ['>= 0', { :path => File.expand_path($1), :require => false }]
   else
     [place, { :require => false }]
   end
@@ -15,17 +12,22 @@ end
 
 group(:development, :test) do
   gem "puppet", *location_for('file://.')
-  gem "facter", *location_for(ENV['FACTER_LOCATION'] || '~> 1.6.4')
-  gem "hiera", *location_for(ENV['HIERA_LOCATION'] || '~> 1.0.0')
-  gem "rack", "~> 1.4.1", :require => false
-  gem "rake", "~> 0.9.2", :require => false
-  gem "rspec", "~> 2.10.0", :require => false
+  gem "facter", *location_for(ENV['FACTER_LOCATION'] || '~> 1.6')
+  gem "hiera", *location_for(ENV['HIERA_LOCATION'] || '~> 1.0')
+  gem "rack", "~> 1.4", :require => false
+  gem "rake", :require => false
+  gem "rspec", "~> 2.11.0", :require => false
   gem "mocha", "~> 0.10.5", :require => false
+  gem "activerecord", *location_for('~> 3.0.7')
+  gem "couchrest", *location_for('~> 1.0')
+  gem "net-ssh", *location_for('~> 2.1')
+  gem "puppetlabs_spec_helper"
+  gem "sqlite3"
+  gem "stomp"
+  gem "tzinfo"
 end
 
 platforms :mswin, :mingw do
-  # See http://jenkins.puppetlabs.com/ for current Gem listings for the Windows
-  # CI Jobs.
   gem "sys-admin", "~> 1.5.6", :require => false
   gem "win32-api", "~> 1.4.8", :require => false
   gem "win32-dir", "~> 0.3.7", :require => false

data/README.md

@@ -1,7 +1,9 @@
 Puppet
 ======
 
-Puppet, an automated administrative engine for your Linux and Unix systems, performs
+[![Build Status](https://travis-ci.org/puppetlabs/puppet.png?branch=master)](https://travis-ci.org/puppetlabs/puppet)
+
+Puppet, an automated administrative engine for your Linux, Unix, and Windows systems, performs
 administrative tasks (such as adding users, installing packages, and updating server
 configurations) based on a centralized specification.
 
@@ -14,11 +16,7 @@ Installation
 
 Generally, you need the following things installed:
 
-* A supported Ruby version. Ruby 1.8.5, 1.8.7, and 1.9.2 are fully supported
-  (with a handful of known issues under 1.9.2); Ruby 1.8.1 is supported on a
-  best-effort basis for agent use only. Other versions of Ruby are used at your
-  own risk, and Ruby 1.8.6, 1.9.0, and 1.9.1 are not recommended for
-  compatibility reasons.
+* A supported Ruby version. Ruby 1.8.7, and 1.9.3 are fully supported.
 
 * The Ruby OpenSSL library.  For some reason, this often isn't included
   in the main ruby distributions.  You can test for it by running
@@ -48,4 +46,8 @@ See LICENSE file.
 Support
 -------
 
-Please log tickets and issues at our [Projects site](http://projects.puppetlabs.com)
+Please log tickets and issues at our [Projects
+site](http://projects.puppetlabs.com). A [mailing
+list](https://groups.google.com/forum/?fromgroups#!forum/puppet-users) is
+available for asking questions and getting help from others. In addition there
+is an active #puppet channel on Freenode.

data/README_DEVELOPER.md

@@ -3,36 +3,13 @@
 This file is intended to provide a place for developers and contributors to
 document what other developers need to know about changes made to Puppet.
 
-# Use of RVM considered dangerous #
+# Internal Structures
 
-Use of RVM in production situations, e.g. running CI tests against this
-repository, is considered dangerous.  The reason we consider RVM to be
-dangerous is because the default behavior of RVM is to hijack the builtin
-behavior of the shell, causing Gemfile files to be loaded and evaluated when
-the shell changes directories into the project root.
-
-This behavior causes the CI Job execution environment that runs with `set -e`
-to be incompatible with RVM.
-
-We work around this issue by disabling the per-project RC file parsing using
-
-    if ! grep -qx rvm_project_rvmrc=0 ~/.rvmrc; then
-      echo rvm_project_rvmrc=0 >> ~/.rvmrc
-    fi
-
-When we setup CI nodes, but this is not standard or expected behavior.
-
-Please consider rbenv instead of rvm.  The default behavior of rvm is difficult
-to maintain with `set -e` shell environments.
-
-# Two Types of Catalog
+## Two Types of Catalog
 
 When working on subsystems of Puppet that deal with the catalog it is important
-to be aware of the two different types of Catalog.  I often ran into this when
-working in Professional Services when I built a small tool to diff two catalogs
-to determine if an upgrade in Puppet produces the same configuration catalogs.
-As a developer I've run into this difference while working on spec tests for
-the static compiler and working on spec tests for types and providers.
+to be aware of the two different types of Catalog.  Developers will often find
+this difference while working on the static compiler and types and providers.
 
 The two different types of catalog becomes relevant when writing spec tests
 because we frequently need to wire up a fake catalog so that we can exercise
@@ -48,7 +25,7 @@ is used to apply the configuration model to the system.
 Resource dependency information is most easily obtained from a RAL catalog by
 walking the graph instance produced by the `relationship_graph` method.
 
-## Resource Catalog
+### Resource Catalog
 
 If you're writing spec tests for something that deals with a catalog "server
 side," a new catalog terminus for example, then you'll be dealing with a
@@ -73,7 +50,7 @@ Resource dependencies are not easily walked using a resource catalog however.
 To walk the dependency tree convert the catalog to a RAL catalog as described
 in
 
-## RAL Catalog
+### RAL Catalog
 
 The resource catalog may be converted to a RAL catalog using `catalog.to_ral`.
 The RAL catalog contains `Puppet::Type` instances instead of `Puppet::Resource`
@@ -403,7 +380,7 @@ This special filebucket resource named "puppet" will cause the agent to fetch
 file contents specified by checksum from the remote filebucket instead of the
 default clientbucket.
 
-## Quick start
+## Trying out the Static Compiler
 
 Create a module that recursively downloads something.  The jeffmccune-filetest
 module will recursively copy the rubygems source tree.
@@ -434,4 +411,18 @@ checksum representing the content.  When managing an out of sync file resource,
 the real contents should be fetched from the server instead of the
 clientbucket.
 
+Package Maintainers
+=====
+
+Software Version API
+-----
+
+Please see the public API regarding the software version as described in
+`lib/puppet/version.rb`.  Puppet provides the means to easily specify the exact
+version of the software packaged using the VERSION file, for example:
+
+    $ git describe --match "3.0.*" > lib/puppet/VERSION
+    $ ruby -r puppet/version -e 'puts Puppet.version'
+    3.0.1-260-g9ca4e54
+
 EOF

data/conf/auth.conf

@@ -1,15 +1,19 @@
-# This is an example auth.conf file, which implements the
-# defaults used by the puppet master.
+# This is the default auth.conf file, which implements the default rules
+# used by the puppet master. (That is, the rules below will still apply
+# even if this file is deleted.)
 #
-# The ACLs are evaluated in top-down order. More general
-# stanzas should be towards the bottom of the file and more
-# specific ones at the top, otherwise the general rules
-# take precedence and later rules will not be evaluated.
+# The ACLs are evaluated in top-down order. More specific stanzas should
+# be towards the top of the file and more general ones at the bottom;
+# otherwise, the general rules may "steal" requests that should be
+# governed by the specific rules.
+#
+# See http://docs.puppetlabs.com/guides/rest_auth_conf.html for a more complete
+# description of auth.conf's behavior.
 #
 # Supported syntax:
-# Each stanza in auth.conf starts with a path to mach, followed
+# Each stanza in auth.conf starts with a path to match, followed
 # by optional modifiers, and finally, a series of allow or deny
-# directives. 
+# directives.
 #
 # Example Stanza
 # ---------------------------------
@@ -18,25 +22,33 @@
 # [environment envlist]
 # [method methodlist]
 # [auth[enthicated] {yes|no|on|off|any}]
-# allow [host|backreference|*]
-# deny [host|backreference|*]
+# allow [host|backreference|*|regex]
+# deny [host|backreference|*|regex]
 # allow_ip [ip|cidr|ip_wildcard|*]
 # deny_ip [ip|cidr|ip_wildcard|*]
 #
-# The path match can either be a simple prefix match or a regular 
+# The path match can either be a simple prefix match or a regular
 # expression. `path /file` would match both `/file_metadata` and
 # `/file_content`. Regex matches allow the use of backreferences
 # in the allow/deny directives.
-# 
+#
 # The regex syntax is the same as for Ruby regex, and captures backreferences
 # for use in the `allow` and `deny` lines of that stanza
 #
 # Examples:
-# path ~ ^/path/to/resource    # equivalent to `path /path/to/resource`
-# allow *
 #
-# path ~ ^/catalog/([^/]+)$    # permit access only for the
-# allow $1                     # node whose cert matches the path
+# path ~ ^/path/to/resource    # Equivalent to `path /path/to/resource`.
+# allow *                      # Allow all authenticated nodes (since auth
+#                              # defaults to `yes`).
+#
+# path ~ ^/catalog/([^/]+)$    # Permit nodes to access their own catalog (by
+# allow $1                     # certname), but not any other node's catalog.
+#
+# path ~ ^/file_(metadata|content)/extra_files/  # Only allow certain nodes to
+# auth yes                                       # access the "extra_files"
+# allow /^(.+)\.example\.com$/                   # mount point; note this must
+# allow_ip 192.168.100.0/24                      # go ABOVE the "/file" rule,
+#                                                # since it is more specific.
 #
 # environment:: restrict an ACL to a comma-separated list of environments
 # method:: restrict an ACL to a comma-separated list of HTTP methods
@@ -45,7 +57,7 @@
 # (ie exactly as if auth yes was present).
 #
 
-### Authenticated paths - these apply only when the client
+### Authenticated ACLs - these rules apply only when the client
 ### has a valid certificate and is thus authenticated
 
 # allow nodes to retrieve their own catalog
@@ -68,33 +80,37 @@ path /report
 method save
 allow *
 
-# unconditionally allow access to all file services
-# which means in practice that fileserver.conf will
-# still be used
+# Allow all nodes to access all file services; this is necessary for
+# pluginsync, file serving from modules, and file serving from custom
+# mount points (see fileserver.conf). Note that the `/file` prefix matches
+# requests to both the file_metadata and file_content paths. See "Examples"
+# above if you need more granular access control for custom mount points.
 path /file
 allow *
 
-### Unauthenticated ACL, for clients for which the current master doesn't
-### have a valid certificate; we allow authenticated users, too, because
-### there isn't a great harm in letting that request through.
+### Unauthenticated ACLs, for clients without valid certificates; authenticated
+### clients can also access these paths, though they rarely need to.
 
-# allow access to the master CA
+# allow access to the CA certificate; unauthenticated nodes need this
+# in order to validate the puppet master's certificate
 path /certificate/ca
 auth any
 method find
 allow *
 
+# allow nodes to retrieve the certificate they requested earlier
 path /certificate/
 auth any
 method find
 allow *
 
+# allow nodes to request a new certificate
 path /certificate_request
 auth any
 method find, save
 allow *
 
-# this one is not stricly necessary, but it has the merit
-# of showing the default policy, which is deny everything else
+# deny everything else; this ACL is not strictly necessary, but
+# illustrates the default policy.
 path /
 auth any

data/conf/fileserver.conf

@@ -0,0 +1,41 @@
+# fileserver.conf
+
+# Puppet automatically serves PLUGINS and FILES FROM MODULES: anything in
+# <module name>/files/<file name> is available to authenticated nodes at
+# puppet:///modules/<module name>/<file name>. You do not need to edit this
+# file to enable this.
+
+# MOUNT POINTS
+
+# If you need to serve files from a directory that is NOT in a module,
+# you must create a static mount point in this file:
+#
+# [extra_files]
+#   path /etc/puppet/files
+#   allow *
+#
+# In the example above, anything in /etc/puppet/files/<file name> would be
+# available to authenticated nodes at puppet:///extra_files/<file name>.
+#
+# Mount points may also use three placeholders as part of their path:
+#
+# %H - The node's certname.
+# %h - The portion of the node's certname before the first dot. (Usually the
+#      node's short hostname.)
+# %d - The portion of the node's certname after the first dot. (Usually the
+#      node's domain name.)
+
+# PERMISSIONS
+
+# Every static mount point should have an `allow *` line; setting more
+# granular permissions in this file is deprecated. Instead, you can
+# control file access in auth.conf by controlling the
+# /file_metadata/<mount point> and /file_content/<mount point> paths:
+#
+# path ~ ^/file_(metadata|content)/extra_files/
+# auth yes
+# allow /^(.+)\.example\.com$/
+# allow_ip 192.168.100.0/24
+#
+# If added to auth.conf BEFORE the "path /file" rule, the rule above
+# will add stricter restrictions to the extra_files mount point.

data/conf/tagmail.conf

@@ -0,0 +1,16 @@
+# tagmail.conf
+
+# This file configures the `tagmail` report, which can be enabled by including
+# tagmail in the puppet master's `reports` setting. (`reports = https, tagmail`)
+
+# Each line in this file should consist of a comma-separated list of tags and/or
+# negated tags (`!tag`), a colon, and a comma-separated list of email addresses.
+# The `all` psuedo-tag will email all log events.
+# See http://docs.puppetlabs.com/guides/configuring.html#tagmailconf for
+# a complete description of this file.
+
+# Example:
+
+# all: log-archive@example.com
+# webserver, !mailserver: httpadmins@example.com
+# emerg, crit: james@example.com, zach@example.com, ben@example.com

data/examples/hiera/modules/data/manifests/common.pp

@@ -1,3 +1,4 @@
+# sets the common (across all puppet conf) ntp servers.
 class data::common {
-  $ntpservers = ["ntp1.example.com", "ntp2.example.com"]
+  $ntpservers = ['ntp1.example.com', 'ntp2.example.com']
 }

data/examples/hiera/modules/ntp/manifests/config.pp

@@ -1,5 +1,6 @@
-class ntp::config($ntpservers = hiera("ntpservers")) {
-  file{"/tmp/ntp.conf":
-    content => template("ntp/ntp.conf.erb")
+# lookup ntpservers from hiera, or allow user of class to provide other value
+class ntp::config($ntpservers = hiera('ntpservers')) {
+  file{'/tmp/ntp.conf':
+    content => template('ntp/ntp.conf.erb')
   }
 }

data/examples/hiera/modules/ntp/manifests/data.pp

@@ -1,3 +1,4 @@
+# this class will be loaded using hiera's 'puppet' backend
 class ntp::data {
-  $ntpservers = ["1.pool.ntp.org", "2.pool.ntp.org"]
+  $ntpservers = ['1.pool.ntp.org', '2.pool.ntp.org']
 }

data/examples/hiera/modules/users/manifests/common.pp

@@ -1,3 +1,4 @@
+# notifies
 class users::common {
-  notify{"Adding users::common": }
+  notify{'Adding users::common': }
 }

data/examples/hiera/modules/users/manifests/dc1.pp

@@ -1,3 +1,4 @@
+# notifies
 class users::dc1 {
-  notify{"Adding users::dc1": }
+  notify{'Adding users::dc1': }
 }

data/examples/hiera/modules/users/manifests/development.pp

@@ -1,3 +1,4 @@
+# notifies
 class users::development {
-  notify{"Adding users::development": }
+  notify{'Adding users::development': }
 }

data/examples/hiera/site.pp

@@ -1,3 +1,3 @@
 node default {
-  hiera_include("classes")
+  hiera_include('classes')
 }

data/ext/debian/fileserver.conf

@@ -1,17 +1,41 @@
-# This file consists of arbitrarily named sections/modules
-# defining where files are served from and to whom
+# fileserver.conf
 
-# 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
-#[files]
-#  path /etc/puppet/files
-#  allow *.example.com
-#  deny *.evil.example.com
-#  allow 192.168.0.0/24
+# Puppet automatically serves PLUGINS and FILES FROM MODULES: anything in
+# <module name>/files/<file name> is available to authenticated nodes at
+# puppet:///modules/<module name>/<file name>. You do not need to edit this
+# file to enable this.
 
-#[plugins]
-#  allow *.example.com
-#  deny *.evil.example.com
-#  allow 192.168.0.0/24
+# MOUNT POINTS
+
+# If you need to serve files from a directory that is NOT in a module,
+# you must create a static mount point in this file:
+#
+# [extra_files]
+#   path /etc/puppet/files
+#   allow *
+#
+# In the example above, anything in /etc/puppet/files/<file name> would be
+# available to authenticated nodes at puppet:///extra_files/<file name>.
+#
+# Mount points may also use three placeholders as part of their path:
+#
+# %H - The node's certname.
+# %h - The portion of the node's certname before the first dot. (Usually the
+#      node's short hostname.)
+# %d - The portion of the node's certname after the first dot. (Usually the
+#      node's domain name.)
+
+# PERMISSIONS
+
+# Every static mount point should have an `allow *` line; setting more
+# granular permissions in this file is deprecated. Instead, you can
+# control file access in auth.conf by controlling the
+# /file_metadata/<mount point> and /file_content/<mount point> paths:
+#
+# path ~ ^/file_(metadata|content)/extra_files/
+# auth yes
+# allow /^(.+)\.example\.com$/
+# allow_ip 192.168.100.0/24
+#
+# If added to auth.conf BEFORE the "path /file" rule, the rule above
+# will add stricter restrictions to the extra_files mount point.