Deleting old documentation that somehow made it back into the tree in the switch to git, and refactoring the evaluate_classes method on the compile object so I can use resources as intermediaries, thus making classes do late-binding evaluation.

27 files changed, 478 insertions, 3048 deletions

diff --git a/documentation/Rakefile b/documentation/Rakefile
deleted file mode 100644
index 6bfe4d239..000000000
--- a/documentation/Rakefile
+++ /dev/null
@@ -1,58 +0,0 @@
-# vim: syntax=ruby
-
-require 'bluecloth'
-
-htmlfiles = []
-
-CLEAN = []
-
-FileList['**/*.page'].each do |src|
-    name = src.sub(".page", ".html")
-    htmlfiles << name
-    CLEAN << name
-    file name => [src, "Rakefile"] do
-        File.open(name, "w") do |f|
-            text = File.read(src).sub(/\A^---[^-]+^---$/, '')
-            f.puts BlueCloth.new( text ).to_html
-        end
-    end
-end
-
-task :clean do
-    CLEAN.each do |file|
-        if FileTest.directory?(file)
-            sh %{rm -rf #{file}}
-        elsif FileTest.exists?(file)
-            File.unlink(file)
-        end
-    end
-end
-
-task :html => htmlfiles
-
-task :default => :html
-
-docs = %w{configref typedocs reports functions}
-
-docs.each do |doc|
-    task doc do
-        docs = %x{puppetdoc --mode #{doc}}
-
-        header = "reference/%s.header" % doc
-        if FileTest.exists?(header)
-            headertext = File.read(header)
-        else
-            headertext = ""
-        end
-
-        file = "reference/%s.page" % doc
-
-        puts "Creating %s" % file
-        File.open(file, "w") do |f|
-            f.puts headertext
-            f.puts docs
-        end
-    end
-end
-
-task :docs => docs
diff --git a/documentation/faq.page b/documentation/faq.page
deleted file mode 100644
index 83a83dca6..000000000
--- a/documentation/faq.page
+++ /dev/null
@@ -1,258 +0,0 @@
----
-inMenu: true
-title: FAQ
-orderInfo: 2
----
-What is Puppet?
-----------------
-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.
-
-The primary design goal of Puppet is that it have an expressive enough
-language backed by a powerful enough library that you can write your own
-server automation applications in just a few lines of code.  With Puppet, you
-can express the configuration of your entire network in one program capable of
-realizing the configuration.  The fact that Puppet has open source combined
-with how easily it can be extended means that you can add whatever
-functionality you think is missing and then contribute it back to the main
-project if you desire.
-
-You can learn more about Puppet by reading its [Documentation][].
-
-What license is Puppet released under?
---------------------------------------
-Puppet is open source and is released under the [GNU Public License][].
-
-Why does Puppet exist?
-----------------------
-Luke Kanies, who founded Reductive Labs, has been doing server automation for
-years, and Puppet is the result of his frustration with existing tools.  After
-significant effort spent trying to enhance cfengine, plus a stint at a
-commercial server automation vendor, Luke concluded that the only way to get a
-great automation tool was to develop one.
-
-Puppet is actually the result of years of design and prototyping (called Blink
-during its prototype phases), but only in 2005 was a commercial company
-(Reductive Labs) built to be fully dedicated to its creation.  If Puppet is
-not the most powerful and most flexible server automation platform available,
-then its goals are not being met.
-
-Why does Puppet have its own language?
---------------------------------------
-This actually is a frequently asked question, and people most often ask why I
-did not choose to use something like XML or YAML as the configuration
-format; otherwise people ask why I didn't just choose to just use Ruby as the
-input language.
-
-The input format for Puppet is not XML or YAML because these are data formats
-developed to be easy for computers to handle.  They do not do conditionals
-(although, yes, they support data structures that could be considered
-conditionals), but mostly, they're just horrible human interfaces.  While some
-people are comfortable reading and writing them, there's a reason why we use
-web browsers instead of just reading the HTML directly.  Also, using XML or
-YAML would limit the ability to make sure the interface is declarative -- one
-process might treat an XML configuration differently from another.
-
-As to just using Ruby as the input format, that unnecessarily ties Puppet to
-Ruby, which is undesirable, and Ruby provides a bit too much functionality.
-For more detail, see the [thread][] on the puppet-dev list.
-
-
-How does Puppet compare to cfengine?
-------------------------------------
-Puppet could be said to be the next-generation cfengine.  The overall design
-is heavily influenced by cfengine, but the language is more powerful than
-cfengine's and the library is more flexible.  In addition, Puppet's client and
-server use standard protocols like XMLRPC and are easy to enhance with new
-functionality, so they are well-positioned to become the platform for the
-network applications of the future, while cfengine's client and server rely
-entirely on cfengine-specific protocols and are quite difficult to enhance.
-
-See [How Puppet Compares to Cfengine][] for more information.
-
-How does Puppet compare to available commercial products?
----------------------------------------------------------
-The primary commercial vendors are BladeLogic and OpsWare.  While they both
-have useful product lines, Puppet surpasses them by reframing the entire
-server automation problem -- while the commercial vendors are writing GUI
-applications for you, Reductive Labs is providing a development platform with
-all the features of a great language, like library development, code sharing,
-and the ability to version control your configurations.
-
-Trying to express a complex network configuration entirely through a GUI is an
-exercise in frustration that no one should suffer, but expressing the
-abstraction necessary to share those GUI configurations goes beyond
-frustrating.
-
-Of course, another great difference between Puppet and the commercial products
-is that Puppet is open sourced under the [GNU Public License][].  You can
-[download][] the product, try it out, peruse the source, and make whatever
-modifications you want.  You have to have more than 100 servers just to get a
-demo from the commercial vendors, but Puppet is available for testing by any
-company that needs to reduce its server administration costs.
-
-Who would find Puppet useful?
------------------------------
-Any organization that would like to reduce the cost of maintaining its
-computers could benefit from using Puppet.  However, because the return on
-investment is linked to multiple factors, like current administrative
-overhead, diversity among existing computers, and cost of downtime, it can be
-difficult for organizations to determine whether they should invest in any
-configuration management tools, much less Puppet.  Reductive Labs can always
-be contacted directly at info at reductivelabs.com to help answer this question.
-
-Generally, however, an organization should be using server automation if any
-of the following are true:
-
-* It has high server administration costs
-* It pays a high price for downtime, either because of contracts or
-  opportunity cost
-* It has many servers that are essentially either identical or nearly
-  identical
-* Flexibility and agility in server configuration are essential
-
-Can Puppet manage workstations?
--------------------------------
-Yes, Puppet can manage any type of machine.  We have found that most
-organizations are more concerned with server management than workstation
-management, and frankly, the term 'server' is slightly more aesthetically
-appealing than 'computer', but Puppet would be ideal for organizations with a
-large number of workstations.
-
-Does Puppet run on Windows?
----------------------------
-The short answer is 'not yet'.  It will eventually, but Reductive Labs does
-not yet have the development bandwidth to make this work.
-
-What size organizations should use Puppet?
-------------------------------------------
-There is no minimum or maximum organization size that can benefit from Puppet,
-but there are sizes that are more likely to benefit.  Organizations with fewer
-than 10-20 servers are unlikely to consider maintaining those servers to be a
-real problem, and thus they can avoid investment in tools even though those
-tools could likely provide savings.
-
-There is no real upper limit to who could benefit from using Puppet.
-Obviously as the server count increases the investment must increase somewhat,
-but with Puppet that increase is not linear.
-
-My servers are all unique; can Puppet still help?
--------------------------------------------------
-All servers are at least somewhat unique -- with different host names and
-different IP addresses -- but very few servers are entirely unique, since
-nearly every one runs a relatively standard operating system.  Servers are
-also often very similar to other servers within a single organization -- all
-Solaris servers might have similar security settings, or all web servers might
-have roughly equivalent configurations -- even if they're very different from
-servers in other organizations.  Finally, servers are often needlessly unique,
-in that they have been built and managed manually with no attempt at retaining
-appropriate consistency.
-
-Puppet can help both on the side of consistency and uniqueness.  Puppet
-can be used to express the consistency that should exist, even if
-that consistency spans arbritrary sets of servers based on any type of data
-like operating system, data center, or physical location.  Puppet can also be
-used to handle uniqueness, either by allowing special provision of what makes
-a given host unique or through specifying exceptions to otherwise standard
-classes.
-
-Who is Reductive Labs?
-----------------------
-Reductive Labs is a small, private company focused on reframing the server
-automation problem.  Our primary focus is Puppet, but Reductive Labs also
-provides automation consulting, training, and custom development.  For more
-information email info at reductivelabs.com.
-
-The [Projects][] page lists our active projects.
-
-How Do I Install Puppet?
-------------------------
-
-The [Installation Guide][] documents the fastest way to start using Puppet.
-
-What is a Manifest?
--------------------
-Because the word *script* implies a procedural one-step-after-another program,
-the word does not apply well to Puppet programs.  Thus, we use the word
-*manifest* to describe declarative Puppet programs.  Speaking of applying,
-Puppet *applies* a manifest to a server or a network, rather than *executing*
-it.
-
-How Do I Write Manifests?
--------------------------
-The best way is to download Puppet and just start writing.  There are multiple
-sets of examples, including the [examples][] used in [unit testing][],
-and the [reference][]will obviously be useful.
-
-How Do I Run Manifests?
------------------------
-Once you have Puppet installed according the the [Installation Guide][],
-just run the ``puppet`` executable against your example:
-
-    puppet -v example.pp
-
-How do I contribute?
---------------------
-First join the [Mailing List][] -- there is currently only a development list,
-but as the community grows a user list will be created.  You can also join the
-IRC channel ``#puppet`` on irc.freenode.net, where Puppet's developers will be
-hanging out most days (and nights).
-
-The most valuable contribution you can make, though, is to use Puppet and
-submit your feedback, either directly on IRC or through the mailing list, or
-via the [bug database][].  We're always looking for great ideas to incorporate
-into Puppet.
-
-When is the Next Release?
--------------------------
-There are regular feature and release updates on the [Mailing List][],
-and you can always find the latest release in the [download][] directory.
-
-I keep getting "certificates were not trusted".  What's wrong?
---------------------------------------------------------------
-Historically this has usually been a problem with the client machine having
-such a different date setting that the certificate is not yet valid.
-
-You can figure the problem out by manually verifying the certificate with
-openssl:
-
-    sudo openssl verify -CAfile /etc/puppet/ssl/certs/ca.pem /etc/puppet/ssl/certs/myhostname.domain.com.pem
-
-[Mailing List]: http://mail.madstop.com/mailman/listinfo/puppet-dev
-[Projects]: /projects/
-[Documentation]: documentation/index.html
-[Installation Guide]: documentation/installation.html
-[How Puppet Compares to Cfengine]: documentation/notcfengine.html
-[GNU Public License]: http://www.gnu.org/copyleft/gpl.html
-[examples]: /trac/puppet/browser/trunk/examples/code/
-[unit testing]: http://www.pragmaticprogrammer.com/starter_kit/ut/
-[bug database]: /trac/puppet/report
-[reference]: documentation/typedocs.html
-[download]: /downloads
-[thread]: http://mail.madstop.com/pipermail/puppet-dev/2006-April/000393.html
-
-I'm getting IPv6 errors; what's wrong?
---------------------------------------
-This can apparently happen if Ruby is not compiled with IPv6 support; see the
-[mail thread](http://mail.madstop.com/pipermail/puppet-dev/2006-August/001410.html)
-for more details.  The only known solution is to make sure you're running a
-version of Ruby compiled with IPv6 support.
-
-I'm getting ``tlsv1 alert unknown ca`` errors; what's wrong?
-------------------------------------------------------------
-This problem is caused by ``puppetmasterd`` not being able to read its
-ca certificate.  This problem might occur up to 0.18.4 but has been
-fixed in 0.19.0.  You can probably fix it for versions before 0.19.0 by
-chgrping /etc/puppet/ssl to the puppet group, but ``puppetd`` might
-chgrp it back.  Having ``puppetmasterd`` start as the root group should
-fix the problem permanently until you can upgrade.
-
-How do all of these variables, like ``operatingsystem``, get set?
------------------------------------------------------------------
-The variables are all set by [Facter](/projects/facter).  You can get
-a full listing of the available variables and their values by running
-``facter`` by itself in a shell.
-
-*$Id$*
diff --git a/documentation/index.page b/documentation/index.page
deleted file mode 100644
index 940951258..000000000
--- a/documentation/index.page
+++ /dev/null
@@ -1,71 +0,0 @@
----
-inMenu: false
-directoryName: Puppet
----
-
-Puppet lets you centrally manage every important aspect of your system using a
-cross-platform specification language that manages all the separate elements
-normally aggregated in different files, like users, cron jobs, and hosts,
-along with obviously discrete elements like packages, services, and files.
-
-Puppet's simple declarative specification language provides powerful classing
-abilities for drawing out the similarities between hosts while allowing them
-to be as specific as necessary, and it handles dependency and prerequisite
-relationships between objects clearly and explicitly. Puppet is written
-entirely in [Ruby](http://www.ruby-lang.org/).
-
-Many general questions about Puppet and Reductive are answered in the
-[FAQ](faq.html), such as "How to get started quickly", "How to contribute",
-and "What is Puppet's License? (GPL)")
-
-You can also often get good support on ``#puppet`` on irc.freenode.net;
-Puppet's primary author, Luke Kanies, is usually online there.
-
-## Relevant Links
-
-* [Documentation](/trac/puppet/wiki/DocumentationStart)
-
-    Available documentation on puppet. Including an Introduction, and Language
-    & Type Library References.
-
-* [Puppet Recipe Manager](http://prmweb.hezmatt.org/)
-
-    A CPAN-like site for sharing and downloading Puppet recipes.
-
-* [Cookbook](/trac/puppet/tags/puppet%2Crecipe)
-
-    All of the cookbook recipes on the Puppet wiki.
-
-* [Downloads](/downloads/)
-
-    Puppet source code, Packages (RPMs, debs, etc.), and Ruby GEM packages.
-
-* [Source Code](/svn/puppet/)
-
-    Puppet Subversion Repository
-
-* [Bug Tracker](https://reductivelabs.com/trac/puppet)
-
-    Bug tickets, feature enhancements, and source browsing
-
-* [Configuration Management Blog](http://madstop.com)
-
-    A blog Luke Kanies is maintaining about the development process of Puppet.
-
-## Mailing Lists
-
-* [Puppet User](http://mail.madstop.com/mailman/listinfo/puppet-users)
-
-    The Puppet users mailing list, for any and all Puppet discussion.
-
-* [Puppet Developer](http://mail.madstop.com/mailman/listinfo/puppet-dev)
-
-    The Puppet-dev mailing list, for all public discussions related to the
-    development of puppet.  All emails generated by the bug tracker are also
-    sent to this list.
-
-* [Puppet Commits](http://mail.madstop.com/mailman/listinfo/puppet-commit)
-
-    A read-only list that gets a copy of all subversion commits.
-
-*$Id$*
diff --git a/documentation/reference/configref.header b/documentation/reference/configref.header
deleted file mode 100644
index 854eb1d99..000000000
--- a/documentation/reference/configref.header
+++ /dev/null
@@ -1,94 +0,0 @@
----
-inMenu: true
-title: Configuration Reference
-orderInfo: 40
----
-# Puppet Configuration Reference
-
-## Specifying Configuration Parameters
-
-Every Puppet executable (with the exception of ``puppetdoc``) accepts all of
-the arguments below, but not all of the arguments make sense for every executable.
-Each argument has a section listed with it in parentheses; often, that section
-will map to an executable (e.g., ``puppetd``), in which case it probably only
-makes sense for that one executable.  If ``puppet`` is listed as the section,
-it is most likely an option that is valid for everyone.
-
-This will not always be the case.  I have tried to be as thorough as possible
-in the descriptions of the arguments, so it should be obvious whether an
-argument is appropriate or not.
-
-These arguments can be supplied to the executables either as command-line 
-arugments or in the configuration file for the appropriate executable.  For 
-instance, the command-line invocation below would set the configuration directory
-to /private/puppet
-  
-    $ puppetd --confdir=/private/puppet
-  
-Note that boolean options are turned on and off with a slightly different syntax
-on the command line:
-
-    $ puppetd --storeconfigs
-      
-    $ puppetd --no-storeconfigs
-
-The invocations above will enable and disable, respectively, the storage of 
-the client configuration.
-
-As mentioned above, the configuration parameters can also be stored in a 
-configuration file located in the configuration directory (`/etc/puppet` 
-by default).  The file is named for the executable it is intended for, for
-example `/etc/puppetd.conf` is the configuration file for `puppetd`.
-
-The file, which follows INI-style formatting, should contain a bracketed
-heading named for the executable, followed by pairs of parameters with their
-values.  Here is an example of a very simple `puppetd.conf` file:
-
-    [puppetd]
-        confdir = /private/puppet
-        storeconfigs = true
-    
-Note that boolean parameters must be explicitly specified as `true` or
-`false` as seen above.
-
-If you're starting out with a fresh configuration, you may wish to let
-the executable generate a template configuration file for you by invoking
-the executable in question with the `--genconfig` command.  The executable
-will print a template configuration to standard output, which can be
-redirected to a file like so:
-
-    $ puppetd --genconfig > /etc/puppet/puppetd.conf
-  
-Note that this invocation will "clobber" (throw away) the contents of any
-pre-existing `puppetd.conf` file, so make a backup of your present config
-if it contains valuable information.
-  
-Like the `--genconfig` argument, the executables also accept a `--genmanifest`
-argument, which will generate a manifest that can be used to manage all of 
-Puppet's directories and files and prints it to standard output.  This can
-likewise be redirected to a file:
-
-    $ puppetd --genmanifest > /etc/puppet/manifests/site.pp
-
-Puppet can also create user and group accounts for itself (one `puppet` group
-and one `puppet` user) if it is invoked as `root` with the `--mkusers` argument:
-
-    $ puppetd --mkusers
-  
-## Signals
-
-The `puppetd` and `puppetmasterd` executables catch some signals for special 
-handling.  Both daemons catch (`SIGHUP`), which forces the server to restart 
-tself.  Predictably, interrupt and terminate (`SIGINT` and `SIGHUP`) will shut 
-down the server, whether it be an instance of `puppetd` or `puppetmasterd`.
-
-Sending the `SIGUSR1` signal to an instance of `puppetd` will cause it to 
-immediately begin a new configuration transaction with the server.  This 
-signal has no effect on `puppetmasterd`.
-
-
-## Configuration Parameter Reference
-
-Below is a list of all documented parameters.  Any default values are in ``block type`` at the end of the description.
-
-
diff --git a/documentation/reference/configref.page b/documentation/reference/configref.page
deleted file mode 100644
index d3081fe0c..000000000
--- a/documentation/reference/configref.page
+++ /dev/null
@@ -1,576 +0,0 @@
----
-inMenu: true
-title: Configuration Reference
-orderInfo: 40
----
-# Puppet Configuration Reference
-
-## Specifying Configuration Parameters
-
-Every Puppet executable (with the exception of ``puppetdoc``) accepts all of
-the arguments below, but not all of the arguments make sense for every executable.
-Each argument has a section listed with it in parentheses; often, that section
-will map to an executable (e.g., ``puppetd``), in which case it probably only
-makes sense for that one executable.  If ``puppet`` is listed as the section,
-it is most likely an option that is valid for everyone.
-
-This will not always be the case.  I have tried to be as thorough as possible
-in the descriptions of the arguments, so it should be obvious whether an
-argument is appropriate or not.
-
-These arguments can be supplied to the executables either as command-line 
-arugments or in the configuration file for the appropriate executable.  For 
-instance, the command-line invocation below would set the configuration directory
-to /private/puppet
-  
-    $ puppetd --confdir=/private/puppet
-  
-Note that boolean options are turned on and off with a slightly different syntax
-on the command line:
-
-    $ puppetd --storeconfigs
-      
-    $ puppetd --no-storeconfigs
-
-The invocations above will enable and disable, respectively, the storage of 
-the client configuration.
-
-As mentioned above, the configuration parameters can also be stored in a 
-configuration file located in the configuration directory (`/etc/puppet` 
-by default).  The file is named for the executable it is intended for, for
-example `/etc/puppetd.conf` is the configuration file for `puppetd`.
-
-The file, which follows INI-style formatting, should contain a bracketed
-heading named for the executable, followed by pairs of parameters with their
-values.  Here is an example of a very simple `puppetd.conf` file:
-
-    [puppetd]
-        confdir = /private/puppet
-        storeconfigs = true
-    
-Note that boolean parameters must be explicitly specified as `true` or
-`false` as seen above.
-
-If you're starting out with a fresh configuration, you may wish to let
-the executable generate a template configuration file for you by invoking
-the executable in question with the `--genconfig` command.  The executable
-will print a template configuration to standard output, which can be
-redirected to a file like so:
-
-    $ puppetd --genconfig > /etc/puppet/puppetd.conf
-  
-Note that this invocation will "clobber" (throw away) the contents of any
-pre-existing `puppetd.conf` file, so make a backup of your present config
-if it contains valuable information.
-  
-Like the `--genconfig` argument, the executables also accept a `--genmanifest`
-argument, which will generate a manifest that can be used to manage all of 
-Puppet's directories and files and prints it to standard output.  This can
-likewise be redirected to a file:
-
-    $ puppetd --genmanifest > /etc/puppet/manifests/site.pp
-
-Puppet can also create user and group accounts for itself (one `puppet` group
-and one `puppet` user) if it is invoked as `root` with the `--mkusers` argument:
-
-    $ puppetd --mkusers
-  
-## Signals
-
-The `puppetd` and `puppetmasterd` executables catch some signals for special 
-handling.  Both daemons catch (`SIGHUP`), which forces the server to restart 
-tself.  Predictably, interrupt and terminate (`SIGINT` and `SIGHUP`) will shut 
-down the server, whether it be an instance of `puppetd` or `puppetmasterd`.
-
-Sending the `SIGUSR1` signal to an instance of `puppetd` will cause it to 
-immediately begin a new configuration transaction with the server.  This 
-signal has no effect on `puppetmasterd`.
-
-
-## Configuration Parameter Reference
-
-Below is a list of all documented parameters.  Any default values are in ``block type`` at the end of the description.
-
-
-#### <a name="authconfig">authconfig</a> (<em>puppet</em>)
-
-The configuration file that defines the rights to the different namespaces and methods.  This can be used as a coarse-grained authorization system for both ``puppetd`` and ``puppetmasterd``.  ``/etc/puppet/namespaceauth.conf``
-
-#### <a name="autoflush">autoflush</a> (<em>puppet</em>)
-
-Whether log files should always flush to disk.
-
-#### <a name="autosign">autosign</a> (<em>ca</em>)
-
-Whether to enable autosign.  Valid values are true (which autosigns any key request, and is a very bad idea), false (which never autosigns any key request), and the path to a file, which uses that configuration file to determine which keys to sign.  ``/etc/puppet/autosign.conf``
-
-#### <a name="bucketdir">bucketdir</a> (<em>puppetmasterd</em>)
-
-Where FileBucket files are stored.  ``/var/puppet/bucket``
-
-#### <a name="ca_days">ca_days</a> (<em>ca</em>)
-
-How long a certificate should be valid.  This parameter is deprecated, use ca_ttl instead
-
-#### <a name="ca_md">ca_md</a> (<em>ca</em>)
-
-The type of hash used in certificates.  ``md5``
-
-#### <a name="ca_ttl">ca_ttl</a> (<em>ca</em>)
-
-The default TTL for new certificates; valid values  must be an integer, optionally followed by one of the units  'y' (years of 365 days), 'd' (days), 'h' (hours), or  's' (seconds). The unit defaults to seconds. If this parameter is set, ca_days is ignored. Examples are '3600' (one hour)  and '1825d', which is the same as '5y' (5 years)   ``5y``
-
-#### <a name="cacert">cacert</a> (<em>ca</em>)
-
-The CA certificate.  ``/etc/puppet/ssl/ca/ca_crt.pem``
-
-#### <a name="cacrl">cacrl</a> (<em>ca</em>)
-
-The certificate revocation list (CRL) for the CA. Set this to 'none' if you do not want to use a CRL.  ``/etc/puppet/ssl/ca/ca_crl.pem``
-
-#### <a name="cadir">cadir</a> (<em>ca</em>)
-
-The root directory for the certificate authority.  ``/etc/puppet/ssl/ca``
-
-#### <a name="cakey">cakey</a> (<em>ca</em>)
-
-The CA private key.  ``/etc/puppet/ssl/ca/ca_key.pem``
-
-#### <a name="capass">capass</a> (<em>ca</em>)
-
-Where the CA stores the password for the private key  ``/etc/puppet/ssl/ca/private/ca.pass``
-
-#### <a name="caprivatedir">caprivatedir</a> (<em>ca</em>)
-
-Where the CA stores private certificate information.  ``/etc/puppet/ssl/ca/private``
-
-#### <a name="capub">capub</a> (<em>ca</em>)
-
-The CA public key.  ``/etc/puppet/ssl/ca/ca_pub.pem``
-
-#### <a name="casesensitive">casesensitive</a> (<em>puppet</em>)
-
-Whether matching in case statements and selectors should be case-sensitive.  Case insensitivity is handled by downcasing all values before comparison.
-
-#### <a name="cert_inventory">cert_inventory</a> (<em>ca</em>)
-
-A Complete listing of all certificates  ``/etc/puppet/ssl/ca/inventory.txt``
-
-#### <a name="certdir">certdir</a> (<em>certificates</em>)
-
-The certificate directory.  ``/etc/puppet/ssl/certs``
-
-#### <a name="classfile">classfile</a> (<em>puppetd</em>)
-
-The file in which puppetd stores a list of the classes associated with the retrieved configuratiion.  Can be loaded in the separate ``puppet`` executable using the ``--loadclasses`` option.  ``/etc/puppet/classes.txt``
-
-#### <a name="clientbucketdir">clientbucketdir</a> (<em>filebucket</em>)
-
-Where FileBucket files are stored locally.  ``/var/puppet/clientbucket``
-
-#### <a name="color">color</a> (<em>puppet</em>)
-
-Whether to use colors when logging to the console. Valid values are ``ansi`` (equivalent to ``true``), ``html`` (mostly used during testing with TextMate), and ``false``, which produces no color.  ``ansi``
-
-#### <a name="confdir">confdir</a> (<em>puppet</em>)
-
-The main Puppet configuration directory.  ``/etc/puppet``
-
-#### <a name="config">config</a> (<em>puppetdoc</em>)
-
-The configuration file for puppetdoc.  ``/etc/puppet/puppetdoc.conf``
-
-#### <a name="configprint">configprint</a> (<em>puppet</em>)
-
-Print the value of a specific configuration parameter.  If a parameter is provided for this, then the value is printed and puppet exits.  Comma-separate multiple values.  For a list of all values, specify 'all'.  This feature is only available in Puppet versions higher than 0.18.4.
-
-#### <a name="configtimeout">configtimeout</a> (<em>puppetd</em>)
-
-How long the client should wait for the configuration to be retrieved before considering it a failure.  This can help reduce flapping if too many clients contact the server at one time.  ``30``
-
-#### <a name="csrdir">csrdir</a> (<em>ca</em>)
-
-Where the CA stores certificate requests  ``/etc/puppet/ssl/ca/requests``
-
-#### <a name="dbadapter">dbadapter</a> (<em>puppetmaster</em>)
-
-The type of database to use.  ``sqlite3``
-
-#### <a name="dblocation">dblocation</a> (<em>puppetmaster</em>)
-
-The database cache for client configurations.  Used for querying within the language.  ``/var/puppet/state/clientconfigs.sqlite3``
-
-#### <a name="dbmigrate">dbmigrate</a> (<em>puppetmaster</em>)
-
-Whether to automatically migrate the database.
-
-#### <a name="dbname">dbname</a> (<em>puppetmaster</em>)
-
-The name of the database to use.  ``puppet``
-
-#### <a name="dbpassword">dbpassword</a> (<em>puppetmaster</em>)
-
-The database password for Client caching. Only used when networked databases are used.  ``puppet``
-
-#### <a name="dbserver">dbserver</a> (<em>puppetmaster</em>)
-
-The database server for Client caching. Only used when networked databases are used.  ``localhost``
-
-#### <a name="dbuser">dbuser</a> (<em>puppetmaster</em>)
-
-The database user for Client caching. Only used when networked databases are used.  ``puppet``
-
-#### <a name="downcasefacts">downcasefacts</a> (<em>puppetd</em>)
-
-Whether facts should be made all lowercase when sent to the server.
-
-#### <a name="evaltrace">evaltrace</a> (<em>transaction</em>)
-
-Whether each resource should log when it is being evaluated.  This allows you to interactively see exactly what is being done.
-
-#### <a name="external_nodes">external_nodes</a> (<em>puppet</em>)
-
-An external command that can produce node information.  The first line of output must be either the parent node or blank, and if there is a second line of output it should be a list of whitespace-separated classes to include on that node.  This command makes it straightforward to store your node mapping information in other data sources like databases. For unknown nodes, the commands should exit with an exit code of 1.  ``none``
-
-#### <a name="factdest">factdest</a> (<em>puppet</em>)
-
-Where Puppet should store facts that it pulls down from the central server.  ``/var/puppet/facts``
-
-#### <a name="factpath">factpath</a> (<em>puppet</em>)
-
-Where Puppet should look for facts.  Multiple directories should be colon-separated, like normal PATH variables.  ``/var/puppet/facts``
-
-#### <a name="factsignore">factsignore</a> (<em>puppet</em>)
-
-What files to ignore when pulling down facts.  ``.svn CVS``
-
-#### <a name="factsource">factsource</a> (<em>puppet</em>)
-
-From where to retrieve facts.  The standard Puppet ``file`` type is used for retrieval, so anything that is a valid file source can be used here.  ``puppet://puppet/facts``
-
-#### <a name="factsync">factsync</a> (<em>puppet</em>)
-
-Whether facts should be synced with the central server.
-
-#### <a name="fileserverconfig">fileserverconfig</a> (<em>fileserver</em>)
-
-Where the fileserver configuration is stored.  ``/etc/puppet/fileserver.conf``
-
-#### <a name="filetimeout">filetimeout</a> (<em>puppet</em>)
-
-The minimum time to wait between checking for updates in configuration files.  ``15``
-
-#### <a name="genconfig">genconfig</a> (<em>puppet</em>)
-
-Whether to just print a configuration to stdout and exit.  Only makes sense when used interactively.  Takes into account arguments specified on the CLI.
-
-#### <a name="genmanifest">genmanifest</a> (<em>puppet</em>)
-
-Whether to just print a manifest to stdout and exit.  Only makes sense when used interactively.  Takes into account arguments specified on the CLI.
-
-#### <a name="graph">graph</a> (<em>puppet</em>)
-
-Whether to create dot graph files for the different configuration graphs.  These dot files can be interpreted by tools like OmniGraffle or dot (which is part of ImageMagick).
-
-#### <a name="graphdir">graphdir</a> (<em>puppet</em>)
-
-Where to store dot-outputted graphs.  ``/var/puppet/state/graphs``
-
-#### <a name="group">group</a> (<em>puppetmasterd</em>)
-
-The group puppetmasterd should run as.  ``puppet``
-
-#### <a name="hostcert">hostcert</a> (<em>certificates</em>)
-
-Where individual hosts store and look for their certificates.  ``/etc/puppet/ssl/certs/culain.madstop.com.pem``
-
-#### <a name="hostprivkey">hostprivkey</a> (<em>certificates</em>)
-
-Where individual hosts store and look for their private key.  ``/etc/puppet/ssl/private_keys/culain.madstop.com.pem``
-
-#### <a name="hostpubkey">hostpubkey</a> (<em>certificates</em>)
-
-Where individual hosts store and look for their public key.  ``/etc/puppet/ssl/public_keys/culain.madstop.com.pem``
-
-#### <a name="httplog">httplog</a> (<em>puppetd</em>)
-
-Where the puppetd web server logs.  ``/var/puppet/log/http.log``
-
-#### <a name="ignoreschedules">ignoreschedules</a> (<em>puppetd</em>)
-
-Boolean; whether puppetd should ignore schedules.  This is useful for initial puppetd runs.
-
-#### <a name="keylength">keylength</a> (<em>ca</em>)
-
-The bit length of keys.  ``1024``
-
-#### <a name="ldapattrs">ldapattrs</a> (<em>ldap</em>)
-
-The LDAP attributes to use to define Puppet classes.  Values should be comma-separated.  ``puppetclass``
-
-#### <a name="ldapbase">ldapbase</a> (<em>ldap</em>)
-
-The search base for LDAP searches.  It's impossible to provide a meaningful default here, although the LDAP libraries might have one already set.  Generally, it should be the 'ou=Hosts' branch under your main directory.
-
-#### <a name="ldapnodes">ldapnodes</a> (<em>ldap</em>)
-
-Whether to search for node configurations in LDAP.
-
-#### <a name="ldapparentattr">ldapparentattr</a> (<em>ldap</em>)
-
-The attribute to use to define the parent node.  ``parentnode``
-
-#### <a name="ldappassword">ldappassword</a> (<em>ldap</em>)
-
-The password to use to connect to LDAP.
-
-#### <a name="ldapport">ldapport</a> (<em>ldap</em>)
-
-The LDAP port.  Only used if ``ldapnodes`` is enabled.  ``389``
-
-#### <a name="ldapserver">ldapserver</a> (<em>ldap</em>)
-
-The LDAP server.  Only used if ``ldapnodes`` is enabled.  ``ldap``
-
-#### <a name="ldapssl">ldapssl</a> (<em>ldap</em>)
-
-Whether SSL should be used when searching for nodes. Defaults to false because SSL usually requires certificates to be set up on the client side.
-
-#### <a name="ldapstring">ldapstring</a> (<em>ldap</em>)
-
-The search string used to find an LDAP node.  ``(&(objectclass=puppetClient)(cn=%s))``
-
-#### <a name="ldaptls">ldaptls</a> (<em>ldap</em>)
-
-Whether TLS should be used when searching for nodes. Defaults to false because TLS usually requires certificates to be set up on the client side.
-
-#### <a name="ldapuser">ldapuser</a> (<em>ldap</em>)
-
-The user to use to connect to LDAP.  Must be specified as a full DN.
-
-#### <a name="lexical">lexical</a> (<em>puppet</em>)
-
-Whether to use lexical scoping (vs. dynamic).
-
-#### <a name="listen">listen</a> (<em>puppetd</em>)
-
-Whether puppetd should listen for connections.  If this is true, then by default only the ``runner`` server is started, which allows remote authorized and authenticated nodes to connect and trigger ``puppetd`` runs.
-
-#### <a name="localcacert">localcacert</a> (<em>certificates</em>)
-
-Where each client stores the CA certificate.  ``/etc/puppet/ssl/certs/ca.pem``
-
-#### <a name="localconfig">localconfig</a> (<em>puppetd</em>)
-
-Where puppetd caches the local configuration.  An extension indicating the cache format is added automatically.  ``/etc/puppet/localconfig``
-
-#### <a name="logdir">logdir</a> (<em>puppet</em>)
-
-The Puppet log directory.  ``/var/puppet/log``
-
-#### <a name="manifest">manifest</a> (<em>puppetmasterd</em>)
-
-The entry-point manifest for puppetmasterd.  ``/etc/puppet/manifests/site.pp``
-
-#### <a name="manifestdir">manifestdir</a> (<em>puppetmasterd</em>)
-
-Where puppetmasterd looks for its manifests.  ``/etc/puppet/manifests``
-
-#### <a name="masterhttplog">masterhttplog</a> (<em>puppetmasterd</em>)
-
-Where the puppetmasterd web server logs.  ``/var/puppet/log/masterhttp.log``
-
-#### <a name="masterlog">masterlog</a> (<em>puppetmasterd</em>)
-
-Where puppetmasterd logs.  This is generally not used, since syslog is the default log destination.  ``/var/puppet/log/puppetmaster.log``
-
-#### <a name="masterport">masterport</a> (<em>puppetmasterd</em>)
-
-Which port puppetmasterd listens on.  ``8140``
-
-#### <a name="mkusers">mkusers</a> (<em>puppet</em>)
-
-Whether to create the necessary user and group that puppetd will run as.
-
-#### <a name="node_name">node_name</a> (<em>puppetmasterd</em>)
-
-How the puppetmaster determines the client's identity  and sets the 'hostname' fact for use in the manifest, in particular  for determining which 'node' statement applies to the client.  Possible values are 'cert' (use the subject's CN in the client's  certificate) and 'facter' (use the hostname that the client  reported in its facts)  ``cert``
-
-#### <a name="noop">noop</a> (<em>puppetd</em>)
-
-Whether puppetd should be run in noop mode.
-
-#### <a name="paramcheck">paramcheck</a> (<em>ast</em>)
-
-Whether to validate parameters during parsing.  ``true``
-
-#### <a name="parseonly">parseonly</a> (<em>puppetmasterd</em>)
-
-Just check the syntax of the manifests.
-
-#### <a name="passfile">passfile</a> (<em>certificates</em>)
-
-Where puppetd stores the password for its private key. Generally unused.  ``/etc/puppet/ssl/private/password``
-
-#### <a name="path">path</a> (<em>puppet</em>)
-
-The shell search path.  Defaults to whatever is inherited from the parent process.  ``none``
-
-#### <a name="plugindest">plugindest</a> (<em>puppet</em>)
-
-Where Puppet should store plugins that it pulls down from the central server.  ``/var/puppet/plugins``
-
-#### <a name="pluginpath">pluginpath</a> (<em>puppet</em>)
-
-Where Puppet should look for plugins.  Multiple directories should be colon-separated, like normal PATH variables.  ``/var/puppet/plugins``
-
-#### <a name="pluginsignore">pluginsignore</a> (<em>puppet</em>)
-
-What files to ignore when pulling down plugins.  ``.svn CVS``
-
-#### <a name="pluginsource">pluginsource</a> (<em>puppet</em>)
-
-From where to retrieve plugins.  The standard Puppet ``file`` type is used for retrieval, so anything that is a valid file source can be used here.  ``puppet://puppet/plugins``
-
-#### <a name="pluginsync">pluginsync</a> (<em>puppet</em>)
-
-Whether plugins should be synced with the central server.
-
-#### <a name="privatedir">privatedir</a> (<em>certificates</em>)
-
-Where the client stores private certificate information.  ``/etc/puppet/ssl/private``
-
-#### <a name="privatekeydir">privatekeydir</a> (<em>certificates</em>)
-
-The private key directory.  ``/etc/puppet/ssl/private_keys``
-
-#### <a name="publickeydir">publickeydir</a> (<em>certificates</em>)
-
-The public key directory.  ``/etc/puppet/ssl/public_keys``
-
-#### <a name="puppetdlockfile">puppetdlockfile</a> (<em>puppetd</em>)
-
-A lock file to temporarily stop puppetd from doing anything.  ``/var/puppet/state/puppetdlock``
-
-#### <a name="puppetdlog">puppetdlog</a> (<em>puppetd</em>)
-
-The log file for puppetd.  This is generally not used.  ``/var/puppet/log/puppetd.log``
-
-#### <a name="puppetport">puppetport</a> (<em>puppetd</em>)
-
-Which port puppetd listens on.  ``8139``
-
-#### <a name="railslog">railslog</a> (<em>puppetmaster</em>)
-
-Where Rails-specific logs are sent  ``/var/puppet/log/rails.log``
-
-#### <a name="report">report</a> (<em>puppetd</em>)
-
-Whether to send reports after every transaction.
-
-#### <a name="reportdir">reportdir</a> (<em>reporting</em>)
-
-The directory in which to store reports received from the client.  Each client gets a separate subdirectory.  ``/var/puppet/reports``
-
-#### <a name="reports">reports</a> (<em>reporting</em>)
-
-The list of reports to generate.  All reports are looked for in puppet/reports/<name>.rb, and multiple report names should be comma-separated (whitespace is okay).  ``store``
-
-#### <a name="reportserver">reportserver</a> (<em>puppetd</em>)
-
-The server to which to send transaction reports.  ``puppet``
-
-#### <a name="req_bits">req_bits</a> (<em>ca</em>)
-
-The bit length of the certificates.  ``2048``
-
-#### <a name="rrddir">rrddir</a> (<em>metrics</em>)
-
-The directory where RRD database files are stored. Directories for each reporting host will be created under this directory.  ``/var/puppet/rrd``
-
-#### <a name="rrdgraph">rrdgraph</a> (<em>metrics</em>)
-
-Whether RRD information should be graphed.
-
-#### <a name="rrdinterval">rrdinterval</a> (<em>metrics</em>)
-
-How often RRD should expect data. This should match how often the hosts report back to the server.  ``1800``
-
-#### <a name="rundir">rundir</a> (<em>puppet</em>)
-
-Where Puppet PID files are kept.  ``/var/run/puppet``
-
-#### <a name="runinterval">runinterval</a> (<em>puppetd</em>)
-
-How often puppetd applies the client configuration; in seconds  ``1800``
-
-#### <a name="serial">serial</a> (<em>ca</em>)
-
-Where the serial number for certificates is stored.  ``/etc/puppet/ssl/ca/serial``
-
-#### <a name="server">server</a> (<em>puppetd</em>)
-
-The server to which server puppetd should connect  ``puppet``
-
-#### <a name="setpidfile">setpidfile</a> (<em>puppet</em>)
-
-Whether to store a PID file for the daemon.  ``true``
-
-#### <a name="signeddir">signeddir</a> (<em>ca</em>)
-
-Where the CA stores signed certificates.  ``/etc/puppet/ssl/ca/signed``
-
-#### <a name="ssldir">ssldir</a> (<em>puppet</em>)
-
-Where SSL certificates are kept.  ``/etc/puppet/ssl``
-
-#### <a name="statedir">statedir</a> (<em>puppet</em>)
-
-The directory where Puppet state is stored.  Generally, this directory can be removed without causing harm (although it might result in spurious service restarts).  ``/var/puppet/state``
-
-#### <a name="statefile">statefile</a> (<em>puppet</em>)
-
-Where puppetd and puppetmasterd store state associated with the running configuration.  In the case of puppetmasterd, this file reflects the state discovered through interacting with clients.  ``/var/puppet/state/state.yaml``
-
-#### <a name="storeconfigs">storeconfigs</a> (<em>puppetmaster</em>)
-
-Whether to store each client's configuration.  This requires ActiveRecord from Ruby on Rails.
-
-#### <a name="syslogfacility">syslogfacility</a> (<em>puppet</em>)
-
-What syslog facility to use when logging to syslog.  Syslog has a fixed list of valid facilities, and you must choose one of those; you cannot just make one up.  ``daemon``
-
-#### <a name="tags">tags</a> (<em>transaction</em>)
-
-Tags to use to find resources.  If this is set, then only resources tagged with the specified tags will be applied. Values must be comma-separated.
-
-#### <a name="templatedir">templatedir</a> (<em>puppet</em>)
-
-Where Puppet looks for template files.  ``/var/puppet/templates``
-
-#### <a name="trace">trace</a> (<em>puppet</em>)
-
-Whether to print stack traces on some errors
-
-#### <a name="typecheck">typecheck</a> (<em>ast</em>)
-
-Whether to validate types during parsing.  ``true``
-
-#### <a name="usecacheonfailure">usecacheonfailure</a> (<em>puppetd</em>)
-
-Whether to use the cached configuration when the remote configuration will not compile.  This option is useful for testing new configurations, where you want to fix the broken configuration rather than reverting to a known-good one.  ``true``
-
-#### <a name="user">user</a> (<em>puppetmasterd</em>)
-
-The user puppetmasterd should run as.  ``puppet``
-
-#### <a name="vardir">vardir</a> (<em>puppet</em>)
-
-Where Puppet stores dynamic and growing data.  ``/var/puppet``
-
-
-
-----------------
-
-
-*This page autogenerated on Fri Jan 26 16:40:43 CST 2007*
diff --git a/documentation/reference/functions.header b/documentation/reference/functions.header
deleted file mode 100644
index 9c58cd36a..000000000
--- a/documentation/reference/functions.header
+++ /dev/null
@@ -1,15 +0,0 @@
----
-inMenu: true
-title: Function Reference
-orderInfo: 40 
----
-        
-There are two types of functions in Puppet: Statements and rvalues.
-Statements stand on their own and do not return arguments; they are used for
-performing stand-alone work like importing.  Rvalues return values and can
-only be used in a statement requiring a value, such as an assignment or a case
-statement. 
-
-Here are the functions available in Puppet:
-                        
-
diff --git a/documentation/reference/functions.page b/documentation/reference/functions.page
deleted file mode 100644
index ad2c03f5a..000000000
--- a/documentation/reference/functions.page
+++ /dev/null
@@ -1,51 +0,0 @@
----
-inMenu: true
-title: Function Reference
-orderInfo: 40 
----
-        
-There are two types of functions in Puppet: Statements and rvalues.
-Statements stand on their own and do not return arguments; they are used for
-performing stand-alone work like importing.  Rvalues return values and can
-only be used in a statement requiring a value, such as an assignment or a case
-statement. 
-
-Here are the functions available in Puppet:
-                        
-
-* **alert** (*statement*):  Log a message on the server at level alert.
-
-* **crit** (*statement*):  Log a message on the server at level crit.
-
-* **debug** (*statement*):  Log a message on the server at level debug.
-
-* **defined** (*rvalue*):  Determine whether a given type is defined, either as a native type or a defined type, or whether a resource has been specified.  If you are checking with a resource is defined, use the normal resource reference syntax, e.g., ``File['/etc/passwd']``.
-
-* **emerg** (*statement*):  Log a message on the server at level emerg.
-
-* **err** (*statement*):  Log a message on the server at level err.
-
-* **fail** (*statement*):  Fail with a parse error.
-
-* **include** (*statement*):  Evaluate one or more classes.
-
-* **info** (*statement*):  Log a message on the server at level info.
-
-* **notice** (*statement*):  Log a message on the server at level notice.
-
-* **realize** (*statement*):  Make a virtual object real.  This is useful when you want to know the name of the virtual object and don't want to bother with a full collection.  It is slightly faster than a collection, and, of course, is a bit shorter.  You must pass the object using a reference; e.g.: ``realize User[luke]``.
-
-* **tag** (*statement*):  Add the specified tags to the containing class or definition.  All contained objects will then acquire that tag, also. 
-
-* **tagged** (*rvalue*):  A boolean function that tells you whether the current container is tagged with the specified tags. The tags are ANDed, so thta all of the specified tags must be included for the function to return true.
-
-* **template** (*rvalue*):  Evaluate a template and return its value.  See [the templating docs](/trac/puppet/wiki/PuppetTemplating) for more information.  Note that if multiple templates are specified, their output is all concatenated and returned as the output of the function.
-
-* **warning** (*statement*):  Log a message on the server at level warning.
-
-
-
-----------------
-
-
-*This page autogenerated on Fri Jan 26 16:40:49 CST 2007*
diff --git a/documentation/reference/index.page b/documentation/reference/index.page
deleted file mode 100644
index 809b854d3..000000000
--- a/documentation/reference/index.page
+++ /dev/null
@@ -1,18 +0,0 @@
----
-inMenu: false
-directoryName: Reference
-title: Reference
-orderInfo: 4
-subtreeLevel: 6
----
-
-Reference
-=========
-* [Configuration Parameter Reference](configref.html)
-* [Function Reference](functions.html)
-* [Reports Reference](reports.html)
-* [Type Reference](typedocs.html)
-
-
-
-*$Id: index.page 1843 2006-11-09 20:47:30Z luke $*
diff --git a/documentation/reference/reports.header b/documentation/reference/reports.header
deleted file mode 100644
index f919a1aca..000000000
--- a/documentation/reference/reports.header
+++ /dev/null
@@ -1,19 +0,0 @@
----
-inMenu: true
-title: Reports Reference
-orderInfo: 40 
----
-
-Puppet clients can report back to the server after each
-transaction.  This transaction report is sent as a YAML dump and includes every
-log message that was generated during the transaction along with as many metrics
-as Puppet knows how to collect.
-
-Currently, clients default to not sending in reports; you can enable reporting
-by setting the ``report`` parameter to true.
-
-To use a report, set the ``reports`` parameter on the server; multiple
-reports must be comma-separated.
-
-Puppet provides multiple report handlers that will process client reports:
-
diff --git a/documentation/reference/reports.page b/documentation/reference/reports.page
deleted file mode 100644
index 0319589ae..000000000
--- a/documentation/reference/reports.page
+++ /dev/null
@@ -1,82 +0,0 @@
----
-inMenu: true
-title: Reports Reference
-orderInfo: 40 
----
-
-Puppet clients can report back to the server after each
-transaction.  This transaction report is sent as a YAML dump and includes every
-log message that was generated during the transaction along with as many metrics
-as Puppet knows how to collect.
-
-Currently, clients default to not sending in reports; you can enable reporting
-by setting the ``report`` parameter to true.
-
-To use a report, set the ``reports`` parameter on the server; multiple
-reports must be comma-separated.
-
-Puppet provides multiple report handlers that will process client reports:
-
-## log
-
-Send all received logs to the local log destinations.
-
-## rrdgraph
-
-Graph all available data about hosts using the RRD library.  You
-must have the RRD binary library installed to use this report, which
-you can get from [Tobias Oetiker's site](http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/pub/contrib/).
-
-This report will create, manage, and graph RRD database files for each
-of the metrics generated during transactions, and it will create a
-few simple html files to display the reporting host's graphs.  At this
-point, it will not create a common index file to display links to
-all hosts.
-
-All RRD files and graphs get created in the ``rrddir`` directory.  If
-you want to serve these publicly, you should be able to just alias that
-directory in a web server.
-
-## store
-
-Store the yaml report on disk.  Each host sends its report as a YAML dump
-and this just stores the file on disk, in the ``reportdir`` directory.
-
-These files collect quickly -- one every half hour -- so it is a good idea
-to perform some maintenance on them if you use this report (it's the only
-default report).
-
-## tagmail
-
-This report sends specific log messages to specific email addresses
-based on the tags in the log messages.  See the
-[tag documentation](/trac/puppet/wiki/UsingTags) for more information
-on tags.
-
-To use this report, you must create a ``tagmail.conf`` (in the location
-specified by ``tagmap``).  This is a simple file that maps tags to
-email addresses:  Any log messages in the report that match the specified
-tags will be sent to the specified email addresses.
-
-Tags must be comma-separated, and they can be negated so that messages
-only match when they do not have that tag.  The tags are separated from
-the email addresses by a colon, and the email addresses should also
-be comma-separated.
-
-Lastly, there is an ``all`` tag that will always match all log messages.
-
-Here is an example tagmail.conf:
-
-    all: me@domain.com
-    webserver, !mailserver: httpadmins@domain.com
-
-This will send all messages to ``me@domain.com``, and all messages from
-webservers that are not also from mailservers to ``httpadmins@domain.com``.
-
-
-
-
-----------------
-
-
-*This page autogenerated on Fri Jan 26 16:40:48 CST 2007*
diff --git a/documentation/reference/typedocs.header b/documentation/reference/typedocs.header
deleted file mode 100644
index 69fabd07c..000000000
--- a/documentation/reference/typedocs.header
+++ /dev/null
@@ -1,7 +0,0 @@
----
-inMenu: true
-title: Type Reference
-orderInfo: 40
----
-# Type Reference
-
diff --git a/documentation/reference/typedocs.page b/documentation/reference/typedocs.page
deleted file mode 100644
index 3fff7ff70..000000000
--- a/documentation/reference/typedocs.page
+++ /dev/null
@@ -1,1775 +0,0 @@
----
-inMenu: true
-title: Type Reference
-orderInfo: 40
----
-# Type Reference
-
-## Table of Contents
-1. <a href='#meta-parameters'>Meta-Parameters</a>
-1. <a href='#cron'>Cron</a>
-1. <a href='#exec'>Exec</a>
-1. <a href='#file'>File</a>
-1. <a href='#filebucket'>Filebucket</a>
-1. <a href='#group'>Group</a>
-1. <a href='#host'>Host</a>
-1. <a href='#mount'>Mount</a>
-1. <a href='#notify'>Notify</a>
-1. <a href='#package'>Package</a>
-1. <a href='#resources'>Resources</a>
-1. <a href='#schedule'>Schedule</a>
-1. <a href='#service'>Service</a>
-1. <a href='#sshkey'>Sshkey</a>
-1. <a href='#tidy'>Tidy</a>
-1. <a href='#user'>User</a>
-1. <a href='#yumrepo'>Yumrepo</a>
-1. <a href='#zone'>Zone</a>
-
-<h2><a name="meta-parameters">Meta-Parameters</a></h2>
-
-Metaparameters are parameters that work with any element; they are part of the
-Puppet framework itself rather than being part of the implementation of any
-given instance.  Thus, any defined metaparameter can be used with any instance
-in your manifest, including defined components.
-
-    
-#### alias
-Creates an alias for the object.  Puppet uses this internally when you
-provide a symbolic name:
-
-    file { sshdconfig:
-        path => $operatingsystem ? {
-            solaris => "/usr/local/etc/ssh/sshd_config",
-            default => "/etc/ssh/sshd_config"
-        },
-        source => "..."
-    }
-
-    service { sshd:
-        subscribe => file[sshdconfig]
-    }
-
-When you use this feature, the parser sets ``sshdconfig`` as the name,
-and the library sets that as an alias for the file so the dependency
-lookup for ``sshd`` works.  You can use this parameter yourself,
-but note that only the library can use these aliases; for instance,
-the following code will not work:
-
-    file { "/etc/ssh/sshd_config":
-        owner => root,
-        group => root,
-        alias => sshdconfig
-    }
-
-    file { sshdconfig:
-        mode => 644
-    }
-
-There's no way here for the Puppet parser to know that these two stanzas
-should be affecting the same file.
-
-See the [language tutorial][] for more information.
-
-[language tutorial]: languagetutorial.html
-
-
-#### before
-This parameter is the opposite of **require** -- it guarantees
-that the specified object is applied later than the specifying
-object:
-
-    file { "/var/nagios/configuration":
-        source  => "...",
-        recurse => true,
-        before => exec["nagios-rebuid"]
-    }
-
-    exec { "nagios-rebuild":
-        command => "/usr/bin/make",
-        cwd => "/var/nagios/configuration"
-    }
-
-This will make sure all of the files are up to date before the
-make command is run.
-
-#### check
-States which should have their values retrieved
-but which should not actually be modified.  This is currently used
-internally, but will eventually be used for querying, so that you
-could specify that you wanted to check the install state of all
-packages, and then query the Puppet client daemon to get reports
-on all packages.
-
-#### loglevel
-Sets the level that information will be logged.
-The log levels have the biggest impact when logs are sent to
-syslog (which is currently the default).  Valid values are ``debug``, ``info``, ``notice``, ``warning``, ``err``, ``alert``, ``emerg``, ``crit``, ``verbose``.
-
-#### noop
-Boolean flag indicating whether work should actually
-be done.  Valid values are ``true``, ``false``.
-
-#### notify
-This parameter is the opposite of **subscribe** -- it sends events
-to the specified object:
-
-    file { "/etc/sshd_config":
-        source => "....",
-        notify => service[sshd]
-    }
-
-    service { sshd:
-        ensure => running
-    }
-
-This will restart the sshd service if the sshd config file changes.
-
-#### require
-One or more objects that this object depends on.
-This is used purely for guaranteeing that changes to required objects
-happen before the dependent object.  For instance:
-
-    # Create the destination directory before you copy things down
-    file { "/usr/local/scripts":
-        ensure => directory
-    }
-
-    file { "/usr/local/scripts/myscript":
-        source => "puppet://server/module/myscript",
-        mode => 755,
-        require => file["/usr/local/scripts"]
-    }
-
-Note that Puppet will autorequire everything that it can, and
-there are hooks in place so that it's easy for elements to add new
-ways to autorequire objects, so if you think Puppet could be
-smarter here, let us know.
-
-In fact, the above code was redundant -- Puppet will autorequire
-any parent directories that are being managed; it will
-automatically realize that the parent directory should be created
-before the script is pulled down.
-
-Currently, exec elements will autorequire their CWD (if it is
-specified) plus any fully qualified paths that appear in the
-command.   For instance, if you had an ``exec`` command that ran
-the ``myscript`` mentioned above, the above code that pulls the
-file down would be automatically listed as a requirement to the
-``exec`` code, so that you would always be running againts the
-most recent version.
-
-#### schedule
-On what schedule the object should be managed.  You must create a
-schedule object, and then reference the name of that object to use
-that for your schedule:
-
-    schedule { daily:
-        period => daily,
-        range => "2-4"
-    }
-
-    exec { "/usr/bin/apt-get update":
-        schedule => daily
-    }
-
-The creation of the schedule object does not need to appear in the
-configuration before objects that use it.
-
-#### subscribe
-One or more objects that this object depends on.  Changes in the
-subscribed to objects result in the dependent objects being
-refreshed (e.g., a service will get restarted).  For instance:
-
-    class nagios {
-        file { "/etc/nagios/nagios.conf":
-            source => "puppet://server/module/nagios.conf",
-            alias => nagconf # just to make things easier for me
-        }
-        service { nagios:
-            running => true,
-            subscribe => file[nagconf]
-        }
-    }
-
-#### tag
-Add the specified tags to the associated element.  While all elements
-are automatically tagged with as much information as possible
-(e.g., each class and component containing the element), it can
-be useful to add your own tags to a given element.
-
-Tags are currently useful for things like applying a subset of a
-host's configuration:
-    
-    puppetd --test --tag mytag
-
-This way, when you're testing a configuration you can run just the
-portion you're testing.
-
-
-## Types
-
-- *namevar* is the parameter used to uniquely identify a type instance.
-  This is the parameter that gets assigned when a string is provided before
-  the colon in a type declaration.  In general, only developers will need to
-  worry about which parameter is the ``namevar``.
-  
-  In the following code:
-
-      file { "/etc/passwd":
-          owner => root,
-          group => root,
-          mode => 644
-      }
-
-  "/etc/passwd" is considered the name of the file object (used for things like
-  dependency handling), and because ``path`` is the namevar for ``file``, that
-  string is assigned to the ``path`` parameter.
-
-- *parameters* determine the specific configuration of the instance.  They either
-  directly modify the system (internally, these are called states) or they affect
-  how the instance behaves (e.g., adding a search path for ``exec`` instances
-  or determining recursion on ``file`` instances).
-
-When required binaries are specified for providers, fully qualifed paths
-indicate that the binary must exist at that specific path and unqualified
-binaries indicate that Puppet will search for the binary using the shell
-path.
-
-    
-
-
-----------------
-
-
-<h2><a name='cron'>cron</a></h2>
-Installs and manages cron jobs.  All fields except the command 
-and the user are optional, although specifying no periodic
-fields would result in the command being executed every
-minute.  While the name of the cron job is not part of the actual
-job, it is used by Puppet to store and retrieve it.
-
-If you specify a cron job that matches an existing job in every way
-except name, then the jobs will be considered equivalent and the
-new name will be permanently associated with that job.  Once this
-association is made and synced to disk, you can then manage the job
-normally (e.g., change the schedule of the job).
-
-Example:
-    
-    cron { logrotate:
-        command => "/usr/sbin/logrotate",
-        user => root,
-        hour => 2,
-        minute => 0
-    }
-
-
-
-### Cron Parameters
-#### command
-The command to execute in the cron job.  The environment
-provided to the command varies by local system rules, and it is
-best to always provide a fully qualified command.  The user's
-profile is not sourced when the command is run, so if the
-user's environment is desired it should be sourced manually.
-
-All cron parameters support ``absent`` as a value; this will
-remove any existing values for that field.
-
-#### ensure
-The basic state that the object should be in.  Valid values are ``absent``, ``present``.
-
-#### environment
-Any environment settings associated with this cron job.  They
-will be stored between the header and the job in the crontab.  There
-can be no guarantees that other, earlier settings will not also
-affect a given cron job.
-
-Also, Puppet cannot automatically determine whether an existing,
-unmanaged environment setting is associated with a given cron
-job.  If you already have cron jobs with environment settings,
-then Puppet will keep those settings in the same place in the file,
-but will not associate them with a specific job.
-
-Settings should be specified exactly as they should appear in
-the crontab, e.g., 'PATH=/bin:/usr/bin:/usr/sbin'.  Multiple
-settings should be specified as an array.
-
-#### hour
-The hour at which to run the cron job. Optional;
-if specified, must be between 0 and 23, inclusive.
-
-#### minute
-The minute at which to run the cron job.
-Optional; if specified, must be between 0 and 59, inclusive.
-
-#### month
-The month of the year.  Optional; if specified
-must be between 1 and 12 or the month name (e.g., December).
-
-#### monthday
-The day of the month on which to run the
-command.  Optional; if specified, must be between 1 and 31.
-
-#### name (*namevar*)
-The symbolic name of the cron job.  This name
-is used for human reference only and is generated automatically
-for cron jobs found on the system.  This generally won't
-matter, as Puppet will do its best to match existing cron jobs
-against specified jobs (and Puppet adds a comment to cron jobs it
-adds), but it is at least possible that converting from
-unmanaged jobs to managed jobs might require manual
-intervention.
-
-The names can only have alphanumeric characters plus the '-'
-character.
-
-#### special
-Special schedules only supported on FreeBSD.
-
-#### user
-The user to run the command as.  This user must
-be allowed to run cron jobs, which is not currently checked by
-Puppet.
-
-The user defaults to whomever Puppet is running as.
-
-#### weekday
-The weekday on which to run the command.
-Optional; if specified, must be between 0 and 6, inclusive, with
-0 being Sunday, or must be the name of the day (e.g., Tuesday).
-
-
-
-
-----------------
-
-
-<h2><a name='exec'>exec</a></h2>
-Executes external commands.  It is critical that all commands
-executed using this mechanism can be run multiple times without
-harm, i.e., they are *idempotent*.  One useful way to create idempotent
-commands is to use the *creates* parameter.
-
-It is worth noting that ``exec`` is special, in that it is not
-currently considered an error to have multiple ``exec`` instances
-with the same name.  This was done purely because it had to be this
-way in order to get certain functionality, but it complicates things.
-In particular, you will not be able to use ``exec`` instances that
-share their commands with other instances as a dependency, since
-Puppet has no way of knowing which instance you mean.
-
-For example:
-
-    # defined in the production class
-    exec { "make":
-        cwd => "/prod/build/dir",
-        path => "/usr/bin:/usr/sbin:/bin"
-    }
-
-    . etc. .
-
-    # defined in the test class
-    exec { "make":
-        cwd => "/test/build/dir",
-        path => "/usr/bin:/usr/sbin:/bin"
-    }
-
-Any other type would throw an error, complaining that you had
-the same instance being managed in multiple places, but these are
-obviously different images, so ``exec`` had to be treated specially.
-
-It is recommended to avoid duplicate names whenever possible.
-
-There is a strong tendency to use ``exec`` to do whatever work Puppet
-can't already do; while this is obviously acceptable (and unavoidable)
-in the short term, it is highly recommended to migrate work from ``exec``
-to real Puppet element types as quickly as possible.  If you find that
-you are doing a lot of work with ``exec``, please at least notify
-us at Reductive Labs what you are doing, and hopefully we can work with
-you to get a native element type for the work you are doing.  In general,
-it is a Puppet bug if you need ``exec`` to do your work.
-
-
-### Exec Parameters
-#### command (*namevar*)
-The actual command to execute.  Must either be fully qualified
-or a search path for the command must be provided.  If the command
-succeeds, any output produced will be logged at the instance's
-normal log level (usually ``notice``), but if the command fails
-(meaning its return code does not match the specified code) then
-any output is logged at the ``err`` log level.
-
-#### creates
-A file that this command creates.  If this
-parameter is provided, then the command will only be run
-if the specified file does not exist.
-
-    exec { "tar xf /my/tar/file.tar":
-        cwd => "/var/tmp",
-        creates => "/var/tmp/myfile",
-        path => ["/usr/bin", "/usr/sbin"]
-    }
-
-
-#### cwd
-The directory from which to run the command.  If
-this directory does not exist, the command will fail.
-
-#### env
-Any additional environment variables you want to set for a
-command.  Note that if you use this to set PATH, it will override
-the ``path`` attribute.  Multiple environment variables should be
-specified as an array.
-
-#### group
-The group to run the command as.  This seems to work quite
-haphazardly on different platforms -- it is a platform issue
-not a Ruby or Puppet one, since the same variety exists when
-running commnands as different users in the shell.
-
-#### logoutput
-Whether to log output.  Defaults to logging output at the
-loglevel for the ``exec`` element.  Values are **true**, *false*,
-and any legal log level.  Valid values are ``true``, ``false``, ``debug``, ``info``, ``notice``, ``warning``, ``err``, ``alert``, ``emerg``, ``crit``.
-
-#### onlyif
-If this parameter is set, then this ``exec`` will only run if
-the command returns 0.  For example:
-    
-    exec { "logrotate":
-        path => "/usr/bin:/usr/sbin:/bin",
-        onlyif => "test `du /var/log/messages | cut -f1` -gt 100000"
-    }
-
-This would run ``logrotate`` only if that test returned true.
-
-Note that this command follows the same rules as the main command,
-which is to say that it must be fully qualified if the path is not set.
-
-#### path
-The search path used for command execution.
-Commands must be fully qualified if no path is specified.  Paths
-can be specified as an array or as a colon-separated list.
-
-#### refreshonly
-The command should only be run as a
-refresh mechanism for when a dependent object is changed.  It only
-makes sense to use this option when this command depends on some
-other object; it is useful for triggering an action:
-    
-    # Pull down the main aliases file
-    file { "/etc/aliases":
-        source => "puppet://server/module/aliases"
-    }
-
-    # Rebuild the database, but only when the file changes
-    exec { newaliases:
-        path => ["/usr/bin", "/usr/sbin"],
-        subscribe => file["/etc/aliases"],
-        refreshonly => true
-    }
-
-Note that only ``subscribe`` can trigger actions, not ``require``,
-so it only makes sense to use ``refreshonly`` with ``subscribe``.  Valid values are ``true``, ``false``.
-
-#### returns
-The expected return code.  An error will be returned if the
-executed command returns something else.  Defaults to 0.
-
-#### timeout
-The maximum time the command should take.  If the command takes
-longer than the timeout, the command is considered to have failed
-and will be stopped.  Use any negative number to disable the timeout.
-
-#### unless
-If this parameter is set, then this ``exec`` will run unless
-the command returns 0.  For example:
-    
-    exec { "/bin/echo root >> /usr/lib/cron/cron.allow":
-        path => "/usr/bin:/usr/sbin:/bin",
-        unless => "grep root /usr/lib/cron/cron.allow 2>/dev/null"
-    }
-
-This would add ``root`` to the cron.allow file (on Solaris) unless
-``grep`` determines it's already there.
-
-Note that this command follows the same rules as the main command,
-which is to say that it must be fully qualified if the path is not set.
-
-#### user
-The user to run the command as.  Note that if you
-use this then any error output is not currently captured.  This
-is because of a bug within Ruby.
-
-
-
-
-----------------
-
-
-<h2><a name='file'>file</a></h2>
-Manages local files, including setting ownership and
-permissions, creation of both files and directories, and
-retrieving entire files from remote servers.  As Puppet matures, it
-expected that the ``file`` element will be used less and less to
-manage content, and instead native elements will be used to do so.
-
-If you find that you are often copying files in from a central
-location, rather than using native elements, please contact
-Reductive Labs and we can hopefully work with you to develop a
-native element to support what you are doing.
-
-
-### File Parameters
-#### backup
-Whether files should be backed up before
-being replaced.  The preferred method of backing files up is via
-a ``filebucket``, which stores files by their MD5 sums and allows
-easy retrieval without littering directories with backups.  You
-can specify a local filebucket or a network-accessible
-server-based filebucket.  Alternatively, if you specify any
-value that begins with a ``.`` (e.g., ``.puppet-bak``), then
-Puppet will use copy the file in the same directory with that
-value as the extension of the backup.
-
-Puppet automatically creates a local filebucket named ``puppet`` and
-defaults to backing up there.  To use a server-based filebucket,
-you must specify one in your configuration:
-    
-    filebucket { main:
-        server => puppet
-    }
-
-The ``puppetmasterd`` daemon creates a filebucket by default,
-so you can usually back up to your main server with this
-configuration.  Once you've described the bucket in your
-configuration, you can use it in any file:
-
-    file { "/my/file":
-        source => "/path/in/nfs/or/something",
-        backup => main
-    }
-
-This will back the file up to the central server.
-
-At this point, the benefits of using a filebucket are that you do not
-have backup files lying around on each of your machines, a given
-version of a file is only backed up once, and you can restore
-any given file manually, no matter how old.  Eventually,
-transactional support will be able to automatically restore
-filebucketed files.
-
-#### checksum
-How to check whether a file has changed.  This state is used internally
-for file copying, but it can also be used to monitor files somewhat
-like Tripwire without managing the file contents in any way.  You can
-specify that a file's checksum should be monitored and then subscribe to
-the file from another object and receive events to signify
-checksum changes, for instance.  Valid values are ``time``, ``md5lite``, ``nosum``, ``timestamp``, ``md5``, ``mtime``.  Values can also match ``(?-mix:^\{md5|md5lite|timestamp|mtime|time\})``.
-
-#### content
-Specify the contents of a file as a string.  Newlines, tabs, and
-spaces can be specified using the escaped syntax (e.g., \n for a
-newline).  The primary purpose of this parameter is to provide a
-kind of limited templating:
-
-    define resolve(nameserver1, nameserver2, domain, search) {
-        $str = "search $search
-    domain $domain
-    nameserver $nameserver1
-    nameserver $nameserver2
-    "
-
-        file { "/etc/resolv.conf":
-            content => $str
-        }
-    }
-
-    This attribute is especially useful when used with
-    [templating](/trac/puppet/wiki/PuppetTemplating).
-
-#### ensure
-Whether to create files that don't currently exist.
-Possible values are *absent*, *present* (equivalent to ``exists`` in
-most file tests -- will match any form of file existence, and if the
-file is missing will create an empty file), *file*, and
-*directory*.  Specifying ``absent`` will delete the file, although
-currently this will not recursively delete directories.
-
-Anything other than those values will be considered to be a symlink.
-For instance, the following text creates a link:
-    
-    # Useful on solaris
-    file { "/etc/inetd.conf":
-        ensure => "/etc/inet/inetd.conf"
-    }
-
-You can make relative links:
-    
-    # Useful on solaris
-    file { "/etc/inetd.conf":
-        ensure => "inet/inetd.conf"
-    }
-
-If you need to make a relative link to a file named the same
-as one of the valid values, you must prefix it with ``./`` or
-something similar.
-
-You can also make recursive symlinks, which will create a
-directory structure that maps to the target directory,
-with directories corresponding to each directory
-and links corresponding to each file.  Valid values are ``link``, ``present``, ``absent`` (also called ``false``), ``directory``, ``file``.  Values can also match ``(?-mix:.)``.
-
-#### force
-Force the file operation.  Currently only used when replacing
-directories with links.  Valid values are ``true``, ``false``.
-
-#### group
-Which group should own the file.  Argument can be either group
-name or group ID.
-
-#### ignore
-A parameter which omits action on files matching
-specified patterns during recursion.  Uses Ruby's builtin globbing
-engine, so shell metacharacters are fully supported, e.g. ``[a-z]*``.
-Matches that would descend into the directory structure are ignored,
-e.g., ``*/*``.
-
-#### linkmaker
-An internal parameter used by the *symlink*
-type to do recursive link creation.
-
-#### links
-How to handle links during file actions.  During file copying,
-``follow`` will copy the target file instead of the link, ``manage``
-will copy the link itself, and ``ignore`` will just pass it by.
-When not copying, ``manage`` and ``ignore`` behave equivalently
-(because you cannot really ignore links entirely during local
-recursion), and ``follow`` will manage the file to which the
-link points.  Valid values are ``follow``, ``manage``, ``ignore``.
-
-#### mode
-Mode the file should be.  Currently relatively limited:
-you must specify the exact mode the file should be.
-
-#### owner
-To whom the file should belong.  Argument can be user name or
-user ID.
-
-#### path (*namevar*)
-The path to the file to manage.  Must be fully qualified.
-
-#### purge
-Whether unmanaged files should be purged.  If you have a filebucket
-configured the purged files will be uploaded, but if you do not,
-this will destroy data.  Only use this option for generated
-files unless you really know what you are doing.  This option only
-makes sense when recursively managing directories.  Valid values are ``true``, ``false``.
-
-#### recurse
-Whether and how deeply to do recursive
-management.  Valid values are ``true``, ``false``, ``inf``.  Values can also match ``(?-mix:^[0-9]+$)``.
-
-#### replace
-Whether or not to replace a file that is
-sourced but exists.  This is useful for using file sources
-purely for initialization.  Valid values are ``true`` (also called ``yes``), ``false`` (also called ``no``).
-
-#### source
-Copy a file over the current file.  Uses ``checksum`` to
-determine when a file should be copied.  Valid values are either
-fully qualified paths to files, or URIs.  Currently supported URI
-types are *puppet* and *file*.
-
-This is one of the primary mechanisms for getting content into
-applications that Puppet does not directly support and is very
-useful for those configuration files that don't change much across
-sytems.  For instance:
-
-    class sendmail {
-        file { "/etc/mail/sendmail.cf":
-            source => "puppet://server/module/sendmail.cf"
-        }
-    }
-
-See the [fileserver docs][] for information on how to configure
-and use file services within Puppet.
-
-If you specify multiple file sources for a file, then the first
-source that exists will be used.  This allows you to specify
-what amount to search paths for files:
-
-    file { "/path/to/my/file":
-        source => [
-            "/nfs/files/file.$host",
-            "/nfs/files/file.$operatingsystem",
-            "/nfs/files/file"
-        ]
-    }
-
-This will use the first found file as the source.
-
-You cannot currently copy links using this mechanism; set ``links``
-to ``follow`` if any remote sources are links.
-
-[fileserver docs]: ../installing/fsconfigref.html
-
-
-#### sourceselect
-Whether to copy all valid sources, or just the first one.  Valid values are ``first``, ``all``.
-
-#### target
-The target for creating a link.  Currently, symlinks are the
-only type supported.  Valid values are ``notlink``.  Values can also match ``(?-mix:.)``.
-
-#### type
-A read-only state to check the file type.
-
-
-
-
-----------------
-
-
-<h2><a name='filebucket'>filebucket</a></h2>
-A repository for backing up files.  If no filebucket is
-defined, then files will be backed up in their current directory,
-but the filebucket can be either a host- or site-global repository
-for backing up.  It stores files and returns the MD5 sum, which
-can later be used to retrieve the file if restoration becomes
-necessary.  A filebucket does not do any work itself; instead,
-it can be specified as the value of *backup* in a **file** object.
-
-Currently, filebuckets are only useful for manual retrieval of
-accidentally removed files (e.g., you look in the log for the md5
-sum and retrieve the file with that sum from the filebucket), but
-when transactions are fully supported filebuckets will be used to
-undo transactions.
-
-You will normally want to define a single filebucket for your
-whole network and then use that as the default backup location:
-
-    # Define the bucket
-    filebucket { main: server => puppet }
-
-    # Specify it as the default target
-    File { backup => main }
-
-Puppetmaster servers create a filebucket by default, so this will
-work in a default configuration.
-
-
-
-### Filebucket Parameters
-#### name (*namevar*)
-The name of the filebucket.
-
-#### path
-The path to the local filebucket.  If this is
-not specified, then the bucket is remote and *server* must be
-specified.
-
-#### port
-The port on which the remote server is listening.
-Defaults to the normal Puppet port, 8140.
-
-#### server
-The server providing the filebucket.  If this is
-not specified, then the bucket is local and *path* must be
-specified.
-
-
-
-
-----------------
-
-
-<h2><a name='group'>group</a></h2>
-Manage groups.  This type can only create groups.  Group
-membership must be managed on individual users.  This element type
-uses the prescribed native tools for creating groups and generally
-uses POSIX APIs for retrieving information about them.  It does
-not directly modify /etc/group or anything.
-
-For most platforms, the tools used are ``groupadd`` and its ilk;
-for Mac OS X, NetInfo is used.  This is currently unconfigurable,
-but if you desperately need it to be so, please contact us.
-
-
-### Group Parameters
-#### allowdupe
-Whether to allow duplicate GIDs.  This option does not work on
-FreeBSD (contract to the ``pw`` man page).  Valid values are ``true``, ``false``.
-
-#### ensure
-The basic state that the object should be in.  Valid values are ``absent``, ``present``.
-
-#### gid
-The group ID.  Must be specified numerically.  If not
-specified, a number will be picked, which can result in ID
-differences across systems and thus is not recommended.  The
-GID is picked according to local system standards.
-
-#### name (*namevar*)
-The group name.  While naming limitations vary by
-system, it is advisable to keep the name to the degenerate
-limitations, which is a maximum of 8 characters beginning with
-a letter.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **groupadd**: Group management via ``groupadd`` and its ilk.  The default
-        for most platforms    Required binaries: ``groupadd``, ``groupmod``, ``groupdel``.
-* **netinfo**: Group management using NetInfo.  Default for ``operatingsystem`` == ``darwin``.    Required binaries: ``nireport``, ``niutil``.
-* **pw**: Group management via ``pw``.  Only works on FreeBSD.  Default for ``operatingsystem`` == ``freebsd``.    Required binaries: ``/usr/sbin/pw``.
-
-
-
-
-----------------
-
-
-<h2><a name='host'>host</a></h2>
-Installs and manages host entries.  For most systems, these
-entries will just be in /etc/hosts, but some systems (notably OS X)
-will have different solutions.
-
-
-### Host Parameters
-#### alias
-Any alias the host might have.  Multiple values must be
-specified as an array.  Note that this state has the same name
-as one of the metaparams; using this state to set aliases will
-make those aliases available in your Puppet scripts and also on
-disk.
-
-#### ensure
-The basic state that the object should be in.  Valid values are ``absent``, ``present``.
-
-#### ip
-The host's IP address, IPv4 or IPv6.
-
-#### name (*namevar*)
-The host name.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **netinfo**: Host management in NetInfo.  This provider is highly experimental and is known
-        not to work currently.  Default for ``operatingsystem`` == ``darwin``.    Required binaries: ``nireport``, ``mount``, ``niutil``, ``df``, ``umount``.
-* **parsed**:   
-
-#### target
-The file in which to store service information.  Only used by
-those providers that write to disk (i.e., not NetInfo).
-
-
-
-
-----------------
-
-
-<h2><a name='mount'>mount</a></h2>
-Manages mounted mounts, including putting mount
-information into the mount table. The actual behavior depends 
-on the value of the 'ensure' parameter.
-
-
-### Mount Parameters
-#### atboot
-Whether to mount the mount at boot.  Not all platforms
-support this.
-
-#### blockdevice
-The the device to fsck.  This is state is only valid
-on Solaris, and in most cases will default to the correct
-value.
-
-#### device
-The device providing the mount.  This can be whatever
-device is supporting by the mount, including network
-devices or devices specified by UUID rather than device
-path, depending on the operating system.
-
-#### dump
-Whether to dump the mount.  Not all platforms
-support this.
-
-#### ensure
-Control what to do with this mount. If the value is 
-``present``, the mount is entered into the mount table, 
-but not mounted, if it is ``absent``, the entry is removed 
-from the mount table and the filesystem is unmounted if 
-currently mounted, if it is ``mounted``, the filesystem 
-is entered into the mount table and mounted.  Valid values are ``absent``, ``present`` (also called ``unmounted``), ``mounted``.
-
-#### fstype
-The mount type.  Valid values depend on the
-operating system.
-
-#### name (*namevar*)
-The mount path for the mount.
-
-#### options
-Mount options for the mounts, as they would
-appear in the fstab.
-
-#### pass
-The pass in which the mount is checked.
-
-#### path
-The deprecated name for the mount point.  Please use ``name`` now.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **netinfo**: Mount management in NetInfo.  This provider is highly experimental and is known
-        not to work currently.  Default for ``operatingsystem`` == ``darwin``.    Required binaries: ``nireport``, ``mount``, ``niutil``, ``df``, ``umount``.
-* **parsed**:     Required binaries: ``mount``, ``df``, ``umount``.
-
-#### target
-The file in which to store the mount table.  Only used by
-those providers that write to disk (i.e., not NetInfo).
-
-
-
-
-----------------
-
-
-<h2><a name='notify'>notify</a></h2>
-Sends an arbitrary message to the puppetd run-time log.
-
-
-### Notify Parameters
-#### message
-The message to be sent to the log.
-
-#### name (*namevar*)
-An arbitrary tag for your own reference; the name of the message.
-
-#### withpath
-Whether to not to show the full object path.  Sends the
-message at the current loglevel.  Valid values are ``true``, ``false``.
-
-
-
-
-----------------
-
-
-<h2><a name='package'>package</a></h2>
-Manage packages.  There is a basic dichotomy in package
-support right now:  Some package types (e.g., yum and apt) can
-retrieve their own package files, while others (e.g., rpm and
-sun) cannot.  For those package formats that cannot retrieve
-their own files, you can use the ``source`` parameter to point to
-the correct file.
-
-Puppet will automatically guess the packaging format that you are
-using based on the platform you are on, but you can override it
-using the ``type`` parameter; obviously, if you specify that you
-want to use ``rpm`` then the ``rpm`` tools must be available.
-
-
-### Package Parameters
-#### adminfile
-A file containing package defaults for installing packages.
-This is currently only used on Solaris.  The value will be
-validated according to system rules, which in the case of
-Solaris means that it should either be a fully qualified path
-or it should be in /var/sadm/install/admin.
-
-#### allowcdrom
-Tells apt to allow cdrom sources in the sources.list file.
-Normally apt will bail if you try this.  Valid values are ``true``, ``false``.
-
-#### category
-A read-only parameter set by the package.
-
-#### configfiles
-Whether configfiles should be kept or replaced.  Most packages
-types do not support this parameter.  Valid values are ``keep``, ``replace``.
-
-#### description
-A read-only parameter set by the package.
-
-#### ensure
-What state the package should be in.
-*latest* only makes sense for those packaging formats that can
-retrieve new packages on their own and will throw an error on
-those that cannot.  For those packaging systems that allow you
-to specify package versions, specify them here.  Valid values are ``absent``, ``present`` (also called ``installed``), ``latest``.  Values can also match ``(?-mix:.)``.
-
-#### instance
-A read-only parameter set by the package.
-
-#### name (*namevar*)
-The package name.  This is the name that the packaging
-system uses internally, which is sometimes (especially on Solaris)
-a name that is basically useless to humans.  If you want to
-abstract package installation, then you can use aliases to provide
-a common name to packages:
-
-    # In the 'openssl' class
-    $ssl = $operationgsystem ? {
-        solaris => SMCossl,
-        default => openssl
-    }
-
-    # It is not an error to set an alias to the same value as the
-    # object name.
-    package { $ssl:
-        ensure => installed,
-        alias => openssl
-    }
-
-    . etc. .
-
-    $ssh = $operationgsystem ? {
-        solaris => SMCossh,
-        default => openssh
-    }
-
-    # Use the alias to specify a dependency, rather than
-    # having another selector to figure it out again.
-    package { $ssh:
-        ensure => installed,
-        alias => openssh,
-        require => package[openssl]
-    }
-
-
-#### platform
-A read-only parameter set by the package.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **apple**: Package management based on OS X's builtin packaging system.  This is
-        essentially the simplest and least functional package system in existence --
-        it only supports installation; no deletion or upgrades.  Default for ``operatingsystem`` == ``darwin``.    Required binaries: ``/usr/sbin/installer``.
-* **apt**: Package management via ``apt-get``.  Default for ``operatingsystem`` == ``debian``.    Required binaries: ``/usr/bin/apt-get``, ``/usr/bin/apt-cache``, ``/usr/bin/debconf-set-selections``.
-* **aptitude**: Package management via ``aptitude``.    Required binaries: ``/usr/bin/apt-cache``, ``/usr/bin/aptitude``.
-* **blastwave**: Package management using Blastwave.org's ``pkg-get`` command on Solaris.    Required binaries: ``pkg-get``.
-* **darwinport**: Package management using DarwinPorts on OS X.    Required binaries: ``/opt/local/bin/port``.
-* **dpkg**: Package management via ``dpkg``.  Because this only uses ``dpkg``
-        and not ``apt``, you must specify the source of any packages you want
-        to manage.    Required binaries: ``/usr/bin/dpkg``, ``/usr/bin/dpkg-query``.
-* **freebsd**: The specific form of package management on FreeBSD.  This is an
-        extremely quirky packaging system, in that it freely mixes between
-        ports and packages.  Apparently all of the tools are written in Ruby,
-        so there are plans to rewrite this support to directly use those
-        libraries.    Required binaries: ``/usr/sbin/pkg_info``, ``/usr/sbin/pkg_add``, ``/usr/sbin/pkg_delete``.
-* **gem**: Ruby Gem support.  By default uses remote gems, but you can specify
-        the path to a local gem via ``source``.    Required binaries: ``gem``.
-* **openbsd**: OpenBSD's form of ``pkg_add`` support.  Default for ``operatingsystem`` == ``openbsd``.    Required binaries: ``pkg_info``, ``pkg_add``, ``pkg_delete``.
-* **pkgdmg**: Package management based on Apple's Installer.app and DiskUtility.app    Required binaries: ``/usr/sbin/installer``, ``/usr/bin/hdiutil``, ``/usr/bin/curl``.
-* **portage**: Provides packaging support for Gentoo's portage system.  Default for ``operatingsystem`` == ``gentoo``.    Required binaries: ``/usr/bin/emerge``, ``/usr/bin/eix``.
-* **ports**: Support for FreeBSD's ports.  Again, this still mixes packages
-        and ports.  Default for ``operatingsystem`` == ``freebsd``.    Required binaries: ``/usr/local/sbin/portupgrade``, ``/usr/local/sbin/portversion``, ``/usr/local/sbin/pkg_deinstall``, ``/usr/sbin/pkg_info``.
-* **rpm**: RPM packaging support; should work anywhere with a working ``rpm``
-        binary.    Required binaries: ``rpm``.
-* **sun**: Sun's packaging system.  Requires that you specify the source for
-        the packages you're managing.  Default for ``operatingsystem`` == ``solaris``.    Required binaries: ``/usr/bin/pkginfo``, ``/usr/sbin/pkgrm``, ``/usr/sbin/pkgadd``.
-* **sunfreeware**: Package management using sunfreeware.com's ``pkg-get`` command on Solaris.
-        At this point, support is exactly the same as ``blastwave`` support and
-        has not actually been tested.    Required binaries: ``pkg-get``.
-* **up2date**: Support for Red Hat's proprietary ``up2date`` package update
-        mechanism.  Default for ``operatingsystem`` == ``redhat``.    Required binaries: ``/usr/sbin/up2date-nox``.
-* **yum**: Support via ``yum``.  Default for ``operatingsystem`` == ``fedoracentos``.    Required binaries: ``yum``, ``rpm``.
-
-#### responsefile
-A file containing any necessary answers to questions asked by
-the package.  This is currently only used on Solaris.  The
-value will be validated according to system rules, but it should
-generally be a fully qualified path.
-
-#### root
-A read-only parameter set by the package.
-
-#### source
-Where to find the actual package.  This must be a local file
-(or on a network file system) or a URL that your specific
-packaging type understands; Puppet will not retrieve files for you.
-
-#### status
-A read-only parameter set by the package.
-
-#### type
-Deprecated form of ``provider``.
-
-#### vendor
-A read-only parameter set by the package.
-
-
-
-
-----------------
-
-
-<h2><a name='resources'>resources</a></h2>
-This is a metatype that can manage other resource types.  Any
-metaparams specified here will be passed on to any generated resources,
-so you can purge umanaged resources but set ``noop`` to true so the
-purging is only logged and does not actually happen.
-
-
-### Resources Parameters
-#### name (*namevar*)
-The name of the type to be managed.
-
-#### purge
-Purge unmanaged resources.  This will delete any resource
-that is not specified in your configuration
-and is not required by any specified resources.  Valid values are ``true``, ``false``.
-
-#### unless_system_user
-This keeps system users from being purged.  By default, it
-does not purge users whose UIDs are less than or equal to 500, but you can specify
-a different UID as the inclusive limit.  Valid values are ``true``, ``false``.  Values can also match ``(?-mix:^\d+$)``.
-
-
-
-
-----------------
-
-
-<h2><a name='schedule'>schedule</a></h2>
-Defined schedules for Puppet.  The important thing to understand
-about how schedules are currently implemented in Puppet is that they
-can only be used to stop an element from being applied, they never
-guarantee that it is applied.
-
-Every time Puppet applies its configuration, it will collect the
-list of elements whose schedule does not eliminate them from
-running right then, but there is currently no system in place to
-guarantee that a given element runs at a given time.  If you
-specify a very  restrictive schedule and Puppet happens to run at a
-time within that schedule, then the elements will get applied;
-otherwise, that work may never get done.
-
-Thus, it behooves you to use wider scheduling (e.g., over a couple of
-hours) combined with periods and repetitions.  For instance, if you
-wanted to restrict certain elements to only running once, between
-the hours of two and 4 AM, then you would use this schedule:
-    
-    schedule { maint:
-        range => "2 - 4",
-        period => daily,
-        repeat => 1
-    }
-
-With this schedule, the first time that Puppet runs between 2 and 4 AM,
-all elements with this schedule will get applied, but they won't
-get applied again between 2 and 4 because they will have already
-run once that day, and they won't get applied outside that schedule
-because they will be outside the scheduled range.
-
-Puppet automatically creates a schedule for each valid period with the
-same name as that period (e.g., hourly and daily).  Additionally,
-a schedule named *puppet* is created and used as the default,
-with the following attributes:
-
-    schedule { puppet:
-        period => hourly,
-        repeat => 2
-    }
-
-This will cause elements to be applied every 30 minutes by default.
-
-
-
-### Schedule Parameters
-#### name (*namevar*)
-The name of the schedule.  This name is used to retrieve the
-schedule when assigning it to an object:
-    
-    schedule { daily:
-        period => daily,
-        range => [2, 4]
-    }
-
-    exec { "/usr/bin/apt-get update":
-        schedule => daily
-    }
-
-
-#### period
-The period of repetition for an element.  Choose from among
-a fixed list of *hourly*, *daily*, *weekly*, and *monthly*.
-The default is for an element to get applied every time that
-Puppet runs, whatever that period is.
-
-Note that the period defines how often a given element will get
-applied but not when; if you would like to restrict the hours
-that a given element can be applied (e.g., only at night during
-a maintenance window) then use the ``range`` attribute.
-
-If the provided periods are not sufficient, you can provide a
-value to the *repeat* attribute, which will cause Puppet to
-schedule the affected elements evenly in the period the
-specified number of times.  Take this schedule:
-
-    schedule { veryoften:
-        period => hourly,
-        repeat => 6
-    }
-
-This can cause Puppet to apply that element up to every 10 minutes.
-
-At the moment, Puppet cannot guarantee that level of
-repetition; that is, it can run up to every 10 minutes, but
-internal factors might prevent it from actually running that
-often (e.g., long-running Puppet runs will squash conflictingly
-scheduled runs).
-
-See the ``periodmatch`` attribute for tuning whether to match
-times by their distance apart or by their specific value.  Valid values are ``hourly``, ``daily``, ``weekly``, ``monthly``.
-
-#### periodmatch
-Whether periods should be matched by number (e.g., the two times
-are in the same hour) or by distance (e.g., the two times are
-60 minutes apart). *number*/**distance**  Valid values are ``number``, ``distance``.
-
-#### range
-The earliest and latest that an element can be applied.  This
-is always a range within a 24 hour period, and hours must be
-specified in numbers between 0 and 23, inclusive.  Minutes and
-seconds can be provided, using the normal colon as a separator.
-For instance:
-
-    schedule { maintenance:
-        range => "1:30 - 4:30"
-    }
-
-This is mostly useful for restricting certain elements to being
-applied in maintenance windows or during off-peak hours.
-
-#### repeat
-How often the application gets repeated in a given period.
-Defaults to 1. Must be an integer.
-
-
-
-
-----------------
-
-
-<h2><a name='service'>service</a></h2>
-Manage running services.  Service support unfortunately varies
-widely by platform -- some platforms have very little if any
-concept of a running service, and some have a very codified and
-powerful concept.  Puppet's service support will generally be able
-to make up for any inherent shortcomings (e.g., if there is no
-'status' command, then Puppet will look in the process table for a
-command matching the service name), but the more information you
-can provide the better behaviour you will get.  Or, you can just
-use a platform that has very good service support.
-
-
-### Service Parameters
-#### binary
-The path to the daemon.  This is only used for
-systems that do not support init scripts.  This binary will be
-used to start the service if no ``start`` parameter is
-provided.
-
-#### enable
-Whether a service should be enabled to start at boot.
-This state behaves quite differently depending on the platform;
-wherever possible, it relies on local tools to enable or disable
-a given service.  *true*/*false*/*runlevels*  Valid values are ``true``, ``false``.
-
-#### ensure
-Whether a service should be running.  **true**/*false*  Valid values are ``running`` (also called ``true``), ``stopped`` (also called ``false``).
-
-#### hasrestart
-Specify that an init script has a ``restart`` option.  Otherwise,
-the init script's ``stop`` and ``start`` methods are used.  Valid values are ``true``, ``false``.
-
-#### hasstatus
-Declare the the service's init script has a
-functional status command.  Based on testing, it was found
-that a large number of init scripts on different platforms do
-not support any kind of status command; thus, you must specify
-manually whether the service you are running has such a
-command (or you can specify a specific command using the
-``status`` parameter).
-
-If you do not specify anything, then the service name will be
-looked for in the process table.
-
-#### name (*namevar*)
-The name of the service to run.  This name
-is used to find the service in whatever service subsystem it
-is in.
-
-#### path
-The search path for finding init scripts.
-
-#### pattern
-The pattern to search for in the process table.
-This is used for stopping services on platforms that do not
-support init scripts, and is also used for determining service
-status on those service whose init scripts do not include a status
-command.
-
-If this is left unspecified and is needed to check the status
-of a service, then the service name will be used instead.
-
-The pattern can be a simple string or any legal Ruby pattern.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **base**: The simplest form of service support.  You have to specify
-        enough about your service for this to work; the minimum you can specify
-        is a binary for starting the process, and this same binary will be searched
-        for in the process table to stop the service.  It is preferable to
-        specify start, stop, and status commands, akin to how you would do
-        so using ``init``.    Required binaries: ``kill``.
-* **debian**: Debian's form of ``init``-style management.  The only difference
-        is that this supports service enabling and disabling via ``update-rc.d``.  Default for ``operatingsystem`` == ``debian``.    Required binaries: ``/usr/sbin/update-rc.d``.
-* **gentoo**: Gentoo's form of ``init``-style service
-        management; uses ``rc-update`` for service enabling and disabling.  Default for ``operatingsystem`` == ``gentoo``.    Required binaries: ``/sbin/rc-update``.
-* **init**: Standard init service management.  This provider assumes that the
-        init script has not ``status`` command, because so few scripts do,
-        so you need to either provide a status command or specify via ``hasstatus``
-        that one already exists in the init script.  
-* **redhat**: Red Hat's (and probably many others) form of ``init``-style service
-        management; uses ``chkconfig`` for service enabling and disabling.  Default for ``operatingsystem`` == ``redhatfedorasuse``.    Required binaries: ``/sbin/chkconfig``.
-* **smf**: Support for Sun's new Service Management Framework.  Starting a service
-        is effectively equivalent to enabling it, so there is only support
-        for starting and stopping services, which also enables and disables them,
-        respectively.  Default for ``operatingsystem`` == ``solaris``.    Required binaries: ``/usr/bin/svcs``, ``/usr/sbin/svcadm``.
-
-#### restart
-Specify a *restart* command manually.  If left
-unspecified, the service will be stopped and then started.
-
-#### running
-A place-holder parameter that wraps ``ensure``, because
-``running`` is deprecated.  You should use ``ensure`` instead
-of this, but using this will still work, albeit with a
-warning.
-
-#### start
-Specify a *start* command manually.  Most service subsystems
-support a ``start`` command, so this will not need to be
-specified.
-
-#### status
-Specify a *status* command manually.  If left
-unspecified, the status method will be determined
-automatically, usually by looking for the service in the
-process table.
-
-#### stop
-Specify a *stop* command manually.
-
-#### type
-Deprecated form of ``provder``.
-
-
-
-
-----------------
-
-
-<h2><a name='sshkey'>sshkey</a></h2>
-Installs and manages ssh host keys.  At this point, this type
-only knows how to install keys into /etc/ssh/ssh_known_hosts, and
-it cannot manage user authorized keys yet.
-
-
-### Sshkey Parameters
-#### alias
-Any alias the host might have.  Multiple values must be
-specified as an array.  Note that this state has the same name
-as one of the metaparams; using this state to set aliases will
-make those aliases available in your Puppet scripts.
-
-#### ensure
-The basic state that the object should be in.  Valid values are ``absent``, ``present``.
-
-#### key
-The key itself; generally a long string of hex digits.
-
-#### name (*namevar*)
-The host name.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **parsed**:   
-
-#### target
-The file in which to store the mount table.  Only used by
-those providers that write to disk (i.e., not NetInfo).
-
-#### type
-The encryption type used.  Probably ssh-dss or ssh-rsa.  Valid values are ``ssh-dss`` (also called ``dsa``), ``ssh-rsa`` (also called ``rsa``).
-
-
-
-
-----------------
-
-
-<h2><a name='tidy'>tidy</a></h2>
-Remove unwanted files based on specific criteria.  Multiple
-criteria are OR'd together, so a file that is too large but is not
-old enough will still get tidied.
-
-
-### Tidy Parameters
-#### age
-Tidy files whose age is equal to or greater than
-the specified time.  You can choose seconds, minutes,
-hours, days, or weeks by specifying the first letter of any
-of those words (e.g., '1w').
-
-#### backup
-Whether files should be backed up before
-being replaced.  The preferred method of backing files up is via
-a ``filebucket``, which stores files by their MD5 sums and allows
-easy retrieval without littering directories with backups.  You
-can specify a local filebucket or a network-accessible
-server-based filebucket.  Alternatively, if you specify any
-value that begins with a ``.`` (e.g., ``.puppet-bak``), then
-Puppet will use copy the file in the same directory with that
-value as the extension of the backup.
-
-Puppet automatically creates a local filebucket named ``puppet`` and
-defaults to backing up there.  To use a server-based filebucket,
-you must specify one in your configuration:
-    
-    filebucket { main:
-        server => puppet
-    }
-
-The ``puppetmasterd`` daemon creates a filebucket by default,
-so you can usually back up to your main server with this
-configuration.  Once you've described the bucket in your
-configuration, you can use it in any file:
-
-    file { "/my/file":
-        source => "/path/in/nfs/or/something",
-        backup => main
-    }
-
-This will back the file up to the central server.
-
-At this point, the benefits of using a filebucket are that you do not
-have backup files lying around on each of your machines, a given
-version of a file is only backed up once, and you can restore
-any given file manually, no matter how old.  Eventually,
-transactional support will be able to automatically restore
-filebucketed files.
-
-#### path (*namevar*)
-The path to the file or directory to manage.  Must be fully
-qualified.
-
-#### recurse
-If target is a directory, recursively descend
-into the directory looking for files to tidy.
-
-#### rmdirs
-Tidy directories in addition to files; that is, remove
-directories whose age is older than the specified criteria.
-This will only remove empty directories, so all contained
-files must also be tidied before a directory gets removed.
-
-#### size
-Tidy files whose size is equal to or greater than
-the specified size.  Unqualified values are in kilobytes, but
-*b*, *k*, and *m* can be appended to specify *bytes*, *kilobytes*,
-and *megabytes*, respectively.  Only the first character is
-significant, so the full word can also be used.
-
-#### type
-Set the mechanism for determining age.  Valid values are ``atime``, ``mtime``, ``ctime``.
-
-
-
-
-----------------
-
-
-<h2><a name='user'>user</a></h2>
-Manage users.  Currently can create and modify users, but
-cannot delete them.  Theoretically all of the parameters are
-optional, but if no parameters are specified the comment will
-be set to the user name in order to make the internals work out
-correctly.
-
-This element type uses the prescribed native tools for creating
-groups and generally uses POSIX APIs for retrieving information
-about them.  It does not directly modify /etc/passwd or anything.
-
-For most platforms, the tools used are ``useradd`` and its ilk;
-for Mac OS X, NetInfo is used.  This is currently unconfigurable,
-but if you desperately need it to be so, please contact us.
-
-
-### User Parameters
-#### allowdupe
-Whether to allow duplicate UIDs.  Valid values are ``true``, ``false``.
-
-#### comment
-A description of the user.  Generally is a user's full name.
-
-#### ensure
-The basic state that the object should be in.  Valid values are ``absent``, ``present``.
-
-#### gid
-The user's primary group.  Can be specified numerically or
-by name.
-
-#### groups
-The groups of which the user is a member.  The primary
-group should not be listed.  Multiple groups should be
-specified as an array.
-
-#### home
-The home directory of the user.  The directory must be created
-separately and is not currently checked for existence.
-
-#### membership
-Whether specified groups should be treated as the only groups
-of which the user is a member or whether they should merely
-be treated as the minimum membership list.  Valid values are ``inclusive``, ``minimum``.
-
-#### name (*namevar*)
-User name.  While limitations are determined for
-each operating system, it is generally a good idea to keep to
-the degenerate 8 characters, beginning with a letter.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **netinfo**: User management in NetInfo.  Default for ``operatingsystem`` == ``darwin``.    Required binaries: ``nireport``, ``niutil``.
-* **pw**: User management via ``pw`` on FreeBSD.  Default for ``operatingsystem`` == ``freebsd``.    Required binaries: ``pw``.
-* **useradd**: User management via ``useradd`` and its ilk.    Required binaries: ``useradd``, ``usermod``, ``userdel``.
-
-#### shell
-The user's login shell.  The shell must exist and be
-executable.
-
-#### uid
-The user ID.  Must be specified numerically.  For new users
-being created, if no user ID is specified then one will be
-chosen automatically, which will likely result in the same user
-having different IDs on different systems, which is not
-recommended.
-
-
-
-
-----------------
-
-
-<h2><a name='yumrepo'>yumrepo</a></h2>
-The client-side description of a yum repository. Repository
-configurations are found by parsing /etc/yum.conf and
-the files indicated by reposdir in that file (see yum.conf(5)
-for details)
-
-Most parameters are identical to the ones documented 
-in yum.conf(5)
-
-Continuation lines that yum supports for example for the
-baseurl are not supported. No attempt is made to access
-files included with the **include** directive
-
-
-### Yumrepo Parameters
-#### baseurl
-The URL for this repository.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### descr
-A human readable description of the repository. 
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### enabled
-Whether this repository is enabled or disabled. Possible 
-values are '0', and '1'.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:(0|1))``.
-
-#### enablegroups
-Determines whether yum will allow the use of
-package groups for this  repository. Possible 
-values are '0', and '1'.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:(0|1))``.
-
-#### exclude
-List of shell globs. Matching packages will never be
-considered in updates or installs for this repo.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### failovermethod
-Either 'roundrobin' or 'priority'.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:roundrobin|priority)``.
-
-#### gpgcheck
-Whether to check the GPG signature on packages installed
-from this repository. Possible values are '0', and '1'.
-
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:(0|1))``.
-
-#### gpgkey
-The URL for the GPG key with which packages from this
-repository are signed.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### include
-A URL from which to include the config.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### includepkgs
-List of shell globs. If this is set, only packages
-matching one of the globs will be considered for
-update or install.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### keepalive
-Either '1' or '0'. This tells yum whether or not HTTP/1.1 
-keepalive  should  be  used with this repository.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:(0|1))``.
-
-#### metadata_expire
-Number of seconds after which the metadata will expire.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:[0-9]+)``.
-
-#### mirrorlist
-The URL that holds the list of mirrors for this repository.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:.*)``.
-
-#### name (*namevar*)
-The name of the repository.
-
-#### timeout
-Number of seconds to wait for a connection before timing 
-out.
-Set this to 'absent' to remove it from the file completely  Valid values are ``absent``.  Values can also match ``(?-mix:[0-9]+)``.
-
-
-
-
-----------------
-
-
-<h2><a name='zone'>zone</a></h2>
-Solaris zones.
-
-
-### Zone Parameters
-#### autoboot
-Whether the zone should automatically boot.  Valid values are ``true``, ``false``.
-
-#### ensure
-The running state of the zone.  The valid states directly reflect
-the states that ``zoneadm`` provides.  The states are linear,
-in that a zone must be ``configured`` then ``installed``, and
-only then can be ``running``.  Note also that ``halt`` is currently
-used to stop zones.  Valid values are ``absent``, ``configured``, ``installed``, ``running``.
-
-#### id
-The numerical ID of the zone.  This number is autogenerated
-and cannot be changed.
-
-#### inherit
-The list of directories that the zone inherits from the global
-zone.  All directories must be fully qualified.
-
-#### ip
-The IP address of the zone.  IP addresses must be specified
-with the interface, separated by a colon, e.g.: bge0:192.168.0.1.
-For multiple interfaces, specify them in an array.
-
-#### name (*namevar*)
-The name of the zone.
-
-#### path
-The root of the zone's filesystem.  Must be a fully qualified
-file name.  If you include '%s' in the path, then it will be
-replaced with the zone's name.  At this point, you cannot use
-Puppet to move a zone.
-
-#### pool
-The resource pool for this zone.
-
-#### provider
-The specific backend for provider to use. You will
-seldom need to specify this -- Puppet will usually discover the
-appropriate provider for your platform.  Available providers are:
-
-* **solaris**: Provider for Solaris Zones.  Default for ``operatingsystem`` == ``solaris``.    Required binaries: ``/usr/sbin/zoneadm``, ``/usr/sbin/zonecfg``.
-
-#### realhostname
-The actual hostname of the zone.
-
-#### shares
-Number of FSS CPU shares allocated to the zone.
-
-#### sysidcfg
-The text to go into the sysidcfg file when the zone is first
-booted.  The best way is to use a template:
-    
-<pre><code>
-    # $templatedir/sysidcfg
-    system_locale=en_US
-    timezone=GMT
-    terminal=xterms
-    security_policy=NONE
-    root_password=&lt;%= password %>
-    timeserver=localhost
-    name_service=DNS {domain_name=&lt;%= domain %>
-            name_server=&lt;%= nameserver %>}
-    network_interface=primary {hostname=&lt;%= realhostname %>
-            ip_address=&lt;%= ip %>
-            netmask=&lt;%= netmask %>
-            protocol_ipv6=no
-            default_route=&lt;%= defaultroute %>}
-    nfs4_domain=dynamic
-</code></pre>
-
-And then call that:
-
-    zone { myzone:
-        ip => "bge0:192.168.0.23",
-        sysidcfg => template(sysidcfg),
-        path => "/opt/zones/myzone",
-        realhostname => "fully.qualified.domain.name"
-    }
-
-The sysidcfg only matters on the first booting of the zone,
-so Puppet only checks for it at that time.
-        
-
-
-
-
-----------------
-
-
-*This page autogenerated on Fri Jan 26 16:40:46 CST 2007*
diff --git a/lib/puppet/metatype/metaparams.rb b/lib/puppet/metatype/metaparams.rb
index 9825efc61..0e31bb41c 100644
--- a/lib/puppet/metatype/metaparams.rb
+++ b/lib/puppet/metatype/metaparams.rb
@@ -273,8 +273,8 @@ class Puppet::Type
                 # Either of the two retrieval attempts could have returned
                 # nil.
                 unless object
-                    self.fail "Could not retrieve dependency '%s[%s]'" %
-                        [tname.to_s.capitalize, name]
+                    self.fail "Could not retrieve dependency '%s[%s]' of %s" %
+                        [tname.to_s.capitalize, self.ref, name]
                 end
 
                 # Are we requiring them, or vice versa?  See the method docs
diff --git a/lib/puppet/network/handler/facts.rb b/lib/puppet/network/handler/facts.rb
index e0b93f942..4767e8be4 100755
--- a/lib/puppet/network/handler/facts.rb
+++ b/lib/puppet/network/handler/facts.rb
@@ -66,5 +66,3 @@ class Puppet::Network::Handler
         end
     end
 end
-
-# $Id$
diff --git a/lib/puppet/network/handler/master.rb b/lib/puppet/network/handler/master.rb
index e5bfa8122..ace383e9f 100644
--- a/lib/puppet/network/handler/master.rb
+++ b/lib/puppet/network/handler/master.rb
@@ -141,5 +141,3 @@ class Puppet::Network::Handler
         end
     end
 end
-
-# $Id$
diff --git a/lib/puppet/parser/ast/definition.rb b/lib/puppet/parser/ast/definition.rb
new file mode 100644
index 000000000..c44f0f903
--- /dev/null
+++ b/lib/puppet/parser/ast/definition.rb
@@ -0,0 +1,226 @@
+require 'puppet/parser/ast/branch'
+
+class Puppet::Parser::AST
+    # Evaluate the stored parse tree for a given component.  This will
+    # receive the arguments passed to the component and also the type and
+    # name of the component.
+    class Definition < AST::Branch
+        include Puppet::Util
+        include Puppet::Util::Warnings
+        include Puppet::Util::MethodHelper
+        class << self
+            attr_accessor :name
+        end
+
+        # The class name
+        @name = :definition
+
+        attr_accessor :classname, :arguments, :code, :scope, :keyword
+        attr_accessor :exported, :namespace, :parser, :virtual
+
+        # These are retrieved when looking up the superclass
+        attr_accessor :name
+
+        attr_reader :parentclass
+
+        def child_of?(klass)
+            false
+        end
+
+        def evaluate_resource(hash)
+            origscope = hash[:scope]
+            title = hash[:title]
+            args = symbolize_options(hash[:arguments] || {})
+
+            name = args[:name] || title
+
+            exported = hash[:exported]
+            virtual = hash[:virtual]
+
+            pscope = origscope
+            scope = subscope(pscope, title)
+
+            if virtual or origscope.virtual?
+                scope.virtual = true
+            end
+
+            if exported or origscope.exported?
+                scope.exported = true
+            end
+
+            # Additionally, add a tag for whatever kind of class
+            # we are
+            if @classname != "" and ! @classname.nil?
+                @classname.split(/::/).each { |tag| scope.tag(tag) }
+            end
+
+            [name, title].each do |str|
+                unless str.nil? or str =~ /[^\w]/ or str == ""
+                    scope.tag(str)
+                end
+            end
+
+            # define all of the arguments in our local scope
+            if self.arguments
+                # Verify that all required arguments are either present or
+                # have been provided with defaults.
+                self.arguments.each { |arg, default|
+                    arg = symbolize(arg)
+                    unless args.include?(arg)
+                        if defined? default and ! default.nil?
+                            default = default.safeevaluate :scope => scope
+                            args[arg] = default
+                            #Puppet.debug "Got default %s for %s in %s" %
+                            #    [default.inspect, arg.inspect, @name.inspect]
+                        else
+                            parsefail "Must pass %s to %s of type %s" %
+                                    [arg,title,@classname]
+                        end
+                    end
+                }
+            end
+
+            # Set each of the provided arguments as variables in the
+            # component's scope.
+            args.each { |arg,value|
+                unless validattr?(arg)
+                    parsefail "%s does not accept attribute %s" % [@classname, arg]
+                end
+
+                exceptwrap do
+                    scope.setvar(arg.to_s,args[arg])
+                end
+            }
+
+            unless args.include? :title
+                scope.setvar("title",title)
+            end
+
+            unless args.include? :name
+                scope.setvar("name",name)
+            end
+
+            if self.code
+                return self.code.safeevaluate(:scope => scope)
+            else
+                return nil
+            end
+        end
+
+        def initialize(hash = {})
+            @arguments = nil
+            @parentclass = nil
+            super
+
+            # Convert the arguments to a hash for ease of later use.
+            if @arguments
+                unless @arguments.is_a? Array
+                    @arguments = [@arguments]
+                end
+                oldargs = @arguments
+                @arguments = {}
+                oldargs.each do |arg, val|
+                    @arguments[arg] = val
+                end
+            else
+                @arguments = {}
+            end
+
+            # Deal with metaparams in the argument list.
+            @arguments.each do |arg, defvalue|
+                next unless Puppet::Type.metaparamclass(arg)
+                if defvalue
+                    warnonce "%s is a metaparam; this value will inherit to all contained elements" % arg
+                else
+                    raise Puppet::ParseError,
+                        "%s is a metaparameter; please choose another name" %
+                        name
+                end
+            end
+        end
+
+        def find_parentclass
+            @parser.findclass(namespace, parentclass)
+        end
+
+        # Set our parent class, with a little check to avoid some potential
+        # weirdness.
+        def parentclass=(name)
+            if name == self.classname
+                parsefail "Parent classes must have dissimilar names"
+            end
+
+            @parentclass = name
+        end
+
+        # Hunt down our class object.
+        def parentobj
+            if @parentclass
+                # Cache our result, since it should never change.
+                unless defined?(@parentobj)
+                    unless tmp = find_parentclass
+                        parsefail "Could not find %s %s" % [self.class.name, @parentclass]
+                    end
+
+                    if tmp == self
+                        parsefail "Parent classes must have dissimilar names"
+                    end
+
+                    @parentobj = tmp
+                end
+                @parentobj
+            else
+                nil
+            end
+        end
+
+        # Create a new subscope in which to evaluate our code.
+        def subscope(scope, name = nil)
+            args = {
+                :type => self.classname,
+                :keyword => self.keyword,
+                :namespace => self.namespace
+            }
+
+            args[:name] = name if name
+            scope = scope.newscope(args)
+            scope.source = self
+
+            return scope
+        end
+
+        def to_s
+            classname
+        end
+
+        # Check whether a given argument is valid.  Searches up through
+        # any parent classes that might exist.
+        def validattr?(param)
+            param = param.to_s
+
+            if @arguments.include?(param)
+                # It's a valid arg for us
+                return true
+            elsif param == "name"
+                return true
+#            elsif defined? @parentclass and @parentclass
+#                # Else, check any existing parent
+#                if parent = @scope.lookuptype(@parentclass) and parent != []
+#                    return parent.validarg?(param)
+#                elsif builtin = Puppet::Type.type(@parentclass)
+#                    return builtin.validattr?(param)
+#                else
+#                    raise Puppet::Error, "Could not find parent class %s" %
+#                        @parentclass
+#                end
+            elsif Puppet::Type.metaparam?(param)
+                return true
+            else
+                # Or just return false
+                return false
+            end
+        end
+    end
+end
+
+# $Id$
diff --git a/lib/puppet/parser/ast/hostclass.rb b/lib/puppet/parser/ast/hostclass.rb
index 9b60c692f..f3b0602b1 100644
--- a/lib/puppet/parser/ast/hostclass.rb
+++ b/lib/puppet/parser/ast/hostclass.rb
@@ -1,10 +1,10 @@
-require 'puppet/parser/ast/component'
+require 'puppet/parser/ast/definition'
 
 class Puppet::Parser::AST
     # The code associated with a class.  This is different from components
     # in that each class is a singleton -- only one will exist for a given
     # node.
-    class HostClass < AST::Component
+    class HostClass < AST::Definition
         @name = :class
 
         # Are we a child of the passed class?  Do a recursive search up our
diff --git a/lib/puppet/parser/compile.rb b/lib/puppet/parser/compile.rb
index 710f90273..7159947bf 100644
--- a/lib/puppet/parser/compile.rb
+++ b/lib/puppet/parser/compile.rb
@@ -70,7 +70,7 @@ class Puppet::Parser::Compile
 
         evaluate_ast_node()
 
-        evaluate_classes()
+        evaluate_node_classes()
 
         evaluate_generators()
 
@@ -109,10 +109,16 @@ class Puppet::Parser::Compile
         @environment
     end
 
-    # Evaluate each class in turn.  If there are any classes we can't find,
-    # just tag the configuration and move on.
-    def evaluate_classes(classes = nil)
-        classes ||= node.classes
+    # Evaluate all of the classes specified by the node.
+    def evaluate_node_classes
+        evaluate_classes(@node.classes, @parser.findclass("", ""))
+    end
+
+    # Evaluate each specified class in turn.  If there are any classes we can't
+    # find, just tag the configuration and move on.  This method really just
+    # creates resource objects that point back to the classes, and then the
+    # resources are themselves evaluated later in the process.
+    def evaluate_classes(classes, source)
         found = []
         classes.each do |name|
             if klass = @parser.findclass("", name)
diff --git a/lib/puppet/parser/functions.rb b/lib/puppet/parser/functions.rb
index 895b4f083..05d694310 100644
--- a/lib/puppet/parser/functions.rb
+++ b/lib/puppet/parser/functions.rb
@@ -110,7 +110,7 @@ module Functions
     # Include the specified classes
     newfunction(:include, :doc => "Evaluate one or more classes.") do |vals|
         vals = [vals] unless vals.is_a?(Array)
-        klasses = compile.evaluate_classes(vals)
+        klasses = compile.evaluate_classes(vals, self)
 
         missing = vals.find_all do |klass|
             ! klasses.include?(klass)
diff --git a/lib/puppet/parser/parser_support.rb b/lib/puppet/parser/parser_support.rb
index 660fa8169..be1d73047 100644
--- a/lib/puppet/parser/parser_support.rb
+++ b/lib/puppet/parser/parser_support.rb
@@ -336,7 +336,7 @@ class Puppet::Parser::Parser
             args[param] = options[param] if options[param]
         end
 
-        @astset.definitions[name] = ast AST::Component, args
+        @astset.definitions[name] = ast AST::Definition, args
     end
 
     # Create a new node.  Nodes are special, because they're stored in a global
diff --git a/spec/unit/parser/compile.rb b/spec/unit/parser/compile.rb
new file mode 100755
index 000000000..d22b63545
--- /dev/null
+++ b/spec/unit/parser/compile.rb
@@ -0,0 +1,48 @@
+#!/usr/bin/env ruby
+
+require File.dirname(__FILE__) + '/../../spec_helper'
+
+describe Puppet::Parser::Compile, " when compiling" do
+    before do
+        @node = mock 'node'
+        @parser = mock 'parser'
+        @compile = Puppet::Parser::Compile.new(@node, @parser)
+    end
+
+    def compile_methods
+        [:set_node_parameters, :evaluate_main, :evaluate_ast_node, :evaluate_node_classes, :evaluate_generators, :fail_on_unevaluated,
+            :finish, :store, :extract]
+    end
+
+    # Stub all of the main compile methods except the ones we're specifically interested in.
+    def compile_stub(*except)
+        (compile_methods - except).each { |m| @compile.stubs(m) }
+    end
+
+    it "should set node parameters as variables in the top scope" do
+        params = {"a" => "b", "c" => "d"}
+        @node.stubs(:parameters).returns(params)
+        compile_stub(:set_node_parameters)
+        @compile.compile
+        @compile.topscope.lookupvar("a").should == "b"
+        @compile.topscope.lookupvar("c").should == "d"
+    end
+
+    it "should evaluate any existing classes named in the node" do
+        classes = %w{one two three four}
+        main = stub 'main'
+        one = stub 'one'
+        one.expects(:safeevaluate).with(:scope => @compile.topscope)
+        three = stub 'three'
+        three.expects(:safeevaluate).with(:scope => @compile.topscope)
+        @node.stubs(:name).returns("whatever")
+        @compile.parser.expects(:findclass).with("", "").returns(main)
+        @compile.parser.expects(:findclass).with("", "one").returns(one)
+        @compile.parser.expects(:findclass).with("", "two").returns(nil)
+        @compile.parser.expects(:findclass).with("", "three").returns(three)
+        @compile.parser.expects(:findclass).with("", "four").returns(nil)
+        @node.stubs(:classes).returns(classes)
+        compile_stub(:evaluate_node_classes)
+        @compile.compile
+    end
+end
diff --git a/test/language/ast/definition.rb b/test/language/ast/definition.rb
new file mode 100755
index 000000000..1bbc1a099
--- /dev/null
+++ b/test/language/ast/definition.rb
@@ -0,0 +1,156 @@
+#!/usr/bin/env ruby
+#
+#  Created by Luke A. Kanies on 2006-02-20.
+#  Copyright (c) 2006. All rights reserved.
+
+$:.unshift("../../lib") if __FILE__ =~ /\.rb$/
+
+require 'puppettest'
+require 'mocha'
+require 'puppettest/parsertesting'
+require 'puppettest/resourcetesting'
+
+class TestASTDefinition < Test::Unit::TestCase
+	include PuppetTest
+	include PuppetTest::ParserTesting
+    include PuppetTest::ResourceTesting
+	AST = Puppet::Parser::AST
+
+    def test_initialize
+        parser = mkparser
+
+        # Create a new definition
+        klass = parser.newdefine "yayness",
+            :arguments => [["owner", stringobj("nobody")], %w{mode}],
+            :code => AST::ASTArray.new(
+                :children => [resourcedef("file", "/tmp/$name",
+                        "owner" => varref("owner"), "mode" => varref("mode"))]
+            )
+
+        # Test validattr? a couple different ways
+        [:owner, "owner", :schedule, "schedule"].each do |var|
+            assert(klass.validattr?(var), "%s was not considered valid" % var.inspect)
+        end
+
+        [:random, "random"].each do |var|
+            assert(! klass.validattr?(var), "%s was considered valid" % var.inspect)
+        end
+
+    end
+
+    def test_evaluate
+        parser = mkparser
+        config = mkconfig
+        scope = config.topscope
+        klass = parser.newdefine "yayness",
+            :arguments => [["owner", stringobj("nobody")], %w{mode}],
+            :code => AST::ASTArray.new(
+                :children => [resourcedef("file", "/tmp/$name",
+                        "owner" => varref("owner"), "mode" => varref("mode"))]
+            )
+
+        # Now call it a couple of times
+        # First try it without a required param
+        assert_raise(Puppet::ParseError, "Did not fail when a required parameter was not provided") do
+            klass.evaluate_resource(:scope => scope,
+                :name => "bad",
+                :arguments => {"owner" => "nobody"}
+            )
+        end
+
+        # And make sure it didn't create the file
+        assert_nil(config.findresource("File[/tmp/bad]"),
+            "Made file with invalid params")
+
+        assert_nothing_raised do
+            klass.evaluate_resource(:scope => scope,
+                :title => "first",
+                :arguments => {"mode" => "755"}
+            )
+        end
+
+        firstobj = config.findresource("File[/tmp/first]")
+        assert(firstobj, "Did not create /tmp/first obj")
+
+        assert_equal("file", firstobj.type)
+        assert_equal("/tmp/first", firstobj.title)
+        assert_equal("nobody", firstobj[:owner])
+        assert_equal("755", firstobj[:mode])
+
+        # Make sure we can't evaluate it with the same args
+        assert_raise(Puppet::ParseError) do
+            klass.evaluate_resource(:scope => scope,
+                :title => "first",
+                :arguments => {"mode" => "755"}
+            )
+        end
+
+        # Now create another with different args
+        assert_nothing_raised do
+            klass.evaluate_resource(:scope => scope,
+                :title => "second",
+                :arguments => {"mode" => "755", "owner" => "daemon"}
+            )
+        end
+
+        secondobj = config.findresource("File[/tmp/second]")
+        assert(secondobj, "Did not create /tmp/second obj")
+
+        assert_equal("file", secondobj.type)
+        assert_equal("/tmp/second", secondobj.title)
+        assert_equal("daemon", secondobj[:owner])
+        assert_equal("755", secondobj[:mode])
+    end
+
+    # #539 - definitions should support both names and titles
+    def test_names_and_titles
+        parser, scope, source = mkclassframing
+
+        [
+        {:name => "one", :title => "two"},
+        {:title => "mytitle"},
+        ].each_with_index do |hash, i|
+
+            # Create a definition that uses both name and title
+            klass = parser.newdefine "yayness%s" % i
+
+            subscope = klass.subscope(scope, "yayness%s" % i)
+
+            klass.expects(:subscope).returns(subscope)
+
+            args = {:title => hash[:title]}
+            if hash[:name]
+                args[:arguments] = {:name => hash[:name]}
+            end
+            args[:scope] = scope
+            assert_nothing_raised("Could not evaluate definition with %s" % hash.inspect) do
+                klass.evaluate_resource(args)
+            end
+
+            name = hash[:name] || hash[:title]
+            title = hash[:title]
+            args[:name] ||= name
+
+            assert_equal(name, subscope.lookupvar("name"),
+                "Name did not get set correctly")
+            assert_equal(title, subscope.lookupvar("title"),
+                "title did not get set correctly")
+
+            [:name, :title].each do |param|
+                val = args[param]
+                assert(subscope.tags.include?(val),
+                    "Scope was not tagged with %s" % val)
+            end
+        end
+    end
+
+    # Testing the root cause of #615.  We should be using the fqname for the type, instead
+    # of just the short name.
+    def test_fully_qualified_types
+        parser = mkparser
+        klass = parser.newclass("one::two")
+
+        assert_equal("one::two", klass.classname, "Class did not get fully qualified class name")
+    end
+end
+# $Id$
diff --git a/test/language/ast/hostclass.rb b/test/language/ast/hostclass.rb
index a91d4bb97..1d2121dad 100755
--- a/test/language/ast/hostclass.rb
+++ b/test/language/ast/hostclass.rb
@@ -140,7 +140,7 @@ class TestASTHostClass < Test::Unit::TestCase
 
         ret = nil
         assert_nothing_raised do
-            ret = scope.compile.evaluate_classes(["sub"])
+            ret = scope.compile.evaluate_classes(["sub"], scope)
         end
 
         subscope = scope.class_scope(scope.findclass("sub"))
diff --git a/test/language/compile.rb b/test/language/compile.rb
index 90cbc292e..5fde2500e 100755
--- a/test/language/compile.rb
+++ b/test/language/compile.rb
@@ -148,7 +148,7 @@ class TestCompile < Test::Unit::TestCase
     # The heart of the action.
     def test_compile
         config = mkconfig
-        [:set_node_parameters, :evaluate_main, :evaluate_ast_node, :evaluate_classes, :evaluate_generators, :fail_on_unevaluated, :finish].each do |method|
+        [:set_node_parameters, :evaluate_main, :evaluate_ast_node, :evaluate_node_classes, :evaluate_generators, :fail_on_unevaluated, :finish].each do |method|
             config.expects(method)
         end
         config.expects(:extract).returns(:config)
@@ -268,6 +268,17 @@ class TestCompile < Test::Unit::TestCase
         assert_equal(%w{one two three}, config.send(:tags), "Allowed duplicate tag")
     end
 
+    def test_evaluate_node_classes
+        config = mkconfig
+        main = mock 'main'
+        config.parser.expects(:findclass).with("", "").returns(main)
+        @node.classes = %w{one two three four}
+        config.expects(:evaluate_classes).with(%w{one two three four}, main)
+        assert_nothing_raised("could not call evaluate_node_classes") do
+            config.send(:evaluate_node_classes)
+        end
+    end
+
     def test_evaluate_classes
         config = mkconfig
         classes = {
@@ -286,10 +297,9 @@ class TestCompile < Test::Unit::TestCase
         config.expects(:tag).with("two")
         config.expects(:tag).with("four")
 
-        @node.classes = %w{one two three four}
         result = nil
-        assert_nothing_raised("could not call evaluate_classes") do
-            result = config.send(:evaluate_classes)
+        assert_nothing_raised("could not call evaluate_node_classes") do
+            result = config.send(:evaluate_classes, %w{one two three four}, config.topscope)
         end
         assert_equal(%w{one three}, result, "Did not return the list of evaluated classes")
     end
diff --git a/test/language/parser.rb b/test/language/parser.rb
index 7c43746e7..0406e99ba 100755
--- a/test/language/parser.rb
+++ b/test/language/parser.rb
@@ -785,7 +785,7 @@ file { "/tmp/yayness":
 
         assert_instance_of(AST::HostClass, result.classes["yay"], "Did not create 'yay' class")
         assert_instance_of(AST::HostClass, result.classes[""], "Did not create main class")
-        assert_instance_of(AST::Component, result.definitions["bar"], "Did not create 'bar' definition")
+        assert_instance_of(AST::Definition, result.definitions["bar"], "Did not create 'bar' definition")
         assert_instance_of(AST::Node, result.nodes["foo"], "Did not create 'foo' node")
     end
 
@@ -1118,7 +1118,7 @@ file { "/tmp/yayness":
         mk_module(name, :define => true, :init => [name])
 
         klass = parser.finddefine("", name)
-        assert_instance_of(AST::Component, klass, "Did not autoload class from module init file")
+        assert_instance_of(AST::Definition, klass, "Did not autoload class from module init file")
         assert_equal(name, klass.classname, "Incorrect class was returned")
 
         # Now try it with namespace classes where both classes are in the init file
diff --git a/test/language/resource.rb b/test/language/resource.rb
index 37b0b7e1e..320b958ff 100755
--- a/test/language/resource.rb
+++ b/test/language/resource.rb
@@ -362,7 +362,7 @@ class TestResource < PuppetTest::TestCase
     def test_components_are_not_builtin
         ref = Parser::Resource::Reference.new(:type => "component", :title => "yay")
 
-        assert_nil(ref.builtintype, "Component was considered builtin")
+        assert_nil(ref.builtintype, "Definition was considered builtin")
     end
 
     # The second part of #539 - make sure resources pass the arguments
diff --git a/test/language/snippets.rb b/test/language/snippets.rb
index 5fb11e8cd..c3c60e77f 100755
--- a/test/language/snippets.rb
+++ b/test/language/snippets.rb
@@ -11,7 +11,6 @@ require 'puppettest'
 
 class TestSnippets < Test::Unit::TestCase
 	include PuppetTest
-    include ObjectSpace
 
     def setup
         super
@@ -458,15 +457,28 @@ class TestSnippets < Test::Unit::TestCase
             #eval("alias %s %s" % [testname, mname])
             testname = ("test_" + mname).intern
             self.send(:define_method, testname) {
+                facts = {
+                    "hostname" => "testhost",
+                    "domain" => "domain.com",
+                    "ipaddress" => "127.0.0.1",
+                    "fqdn" => "testhost.domain.com"
+                }
+                Facter.stubs(:each)
+                facts.each do |name, value|
+                    Facter.stubs(:value).with(name).returns(value)
+                end
                 # first parse the file
                 server = Puppet::Network::Handler.master.new(
                     :Manifest => snippet(file),
                     :Local => true
                 )
+                server.send(:fact_handler).stubs(:set)
+                server.send(:fact_handler).stubs(:get).returns(facts)
                 client = Puppet::Network::Client.master.new(
                     :Master => server,
                     :Cache => false
                 )
+                client.class.stubs(:facts).returns(facts)
 
                 assert(client.local)
                 assert_nothing_raised {