11 files changed, 43 insertions, 35 deletions

diff --git a/documentation/big-picture.page b/documentation/big-picture.page
index d09c1309c..0cb21535e 100644
--- a/documentation/big-picture.page
+++ b/documentation/big-picture.page
@@ -103,7 +103,7 @@ user from platform details.
 
 ### Language Example: Class Hierarchy Using Inherit
 
-Inheritance can be used to override default values defined in base classes::
+Inheritance can be used to override default values defined in base classes:
 
     class base {
         file { "/etc/sudoers":
diff --git a/documentation/faq.page b/documentation/faq.page
index 865bc2498..ea729a5c5 100644
--- a/documentation/faq.page
+++ b/documentation/faq.page
@@ -231,3 +231,5 @@ openssl:
 [reference]: typedocs.html
 [download]: /downloads
 [thread]: http://mail.madstop.com/pipermail/puppet-dev/2006-April/000393.html
+
+*$Id$*
diff --git a/documentation/fromsvn.page b/documentation/fromsvn.page
index c08cc3441..0e99579bb 100644
--- a/documentation/fromsvn.page
+++ b/documentation/fromsvn.page
@@ -61,4 +61,5 @@ already know there's a problem and want to report a bug or if you are planning
 on doing development.  It is worth noting that some of these tests necessarily
 modify your system, so unless you know what you are doing, **it is unadvisable
 to run them as root**, and certainly not on a production system.
+
 *$Id$*
diff --git a/documentation/howitworks.page b/documentation/howitworks.page
index 9eb3f0b8b..dfecbcbd7 100644
--- a/documentation/howitworks.page
+++ b/documentation/howitworks.page
@@ -227,7 +227,7 @@ Once the transaction is complete, all of the events are checked to see if
 there are any callbacks associated with them.  Puppet currently only supports
 one type of callback and one way of specifying them:  Calling ``refresh`` on
 objects based on that object subscribing to another object.  For instance,
-take the following snippet::
+take the following snippet:
 
     file { "/etc/ssh/sshd.conf":
         source => "puppet://puppet/config/sshd.conf"
diff --git a/documentation/index.page b/documentation/index.page
index 927a7ca04..dd19920dc 100644
--- a/documentation/index.page
+++ b/documentation/index.page
@@ -90,17 +90,17 @@ The Puppet reference is split into two pieces:
 API Documentation
 =================
 Until I have time to write tutorials on how to extend Puppet, you might find
-some benefit in perusing the [API docs](/downloads/puppet/apidocs).  They're woefully incomplete as of
-the middle of 2006, but I'll be updating them over time.
+some benefit in perusing the [API docs](/downloads/puppet/apidocs).
+They're woefully incomplete as of the middle of 2006, but I'll be
+updating them over time.
 
 Configuration
 ================
-Most Puppet configuration is currently done directly through the executables
-through the use of command-line flags, although this should largely migrate to
-configuration files before 1.0.  As such, the man pages for the respective
-executables is the appropriate place to look for documentation on
-configuration (e.g., ``puppetmasterd`` for serving and ``puppetd`` for the
-client).
+Puppet configuration can be done through per-process configuration
+files (e.g., ``puppetd.conf``) or on the command-line via switches.
+Much of the documentation is available via ``--help`` switches on each
+executable, but most of the useful switches are common to all
+executables and are thus documented in the [executable reference](puppetd-executable-reference.html).
 
 There are some guides already, though:
 
@@ -116,4 +116,5 @@ is additional information available for those who are interested:
 * [Puppet Internals](howitworks.html)
 
 * [How Cfengine compares to Puppet](notcfengine.html)
+
 *$Id$*
diff --git a/documentation/notcfengine.page b/documentation/notcfengine.page
index 8513e7757..40f25ced8 100644
--- a/documentation/notcfengine.page
+++ b/documentation/notcfengine.page
@@ -58,7 +58,7 @@ supports two critical features that cfengine forces you to hack around.
 Puppet supports building higher level objects out of a set of low-level
 objects including the ability to parameterize, and has a built-in ability to
 express relationships between objects.  For instance, here is how you might
-define an 'apache' component::
+define an 'apache' component:
 
     define apache(docroot,htmlsource,configfile) {
         # make sure the package is installed
@@ -142,7 +142,7 @@ languages, for instance.  The two manifests just download Apache's
 configuration from a central server, restarting Apache if the files change at
 all, and also making sure that Apache is always running.
 
-Here's how it looks in puppet::
+Here's how it looks in puppet:
 
     # This would normally be in a separate file, e.g., classes/apache.pp
     class apacheserver {
@@ -167,7 +167,7 @@ Here's how it looks in puppet::
         include apacheserver
     }
 
-And here's how the same configuration looks in cfengine::
+And here's how the same configuration looks in cfengine:
 
     control:
         # this class is necessary later
@@ -220,4 +220,5 @@ There are a few specific items worth noting in this comparison:
   anywhere, and the 'apacheserver' class must be set before any code is
   associated with it.  Neither of these is a big deal in small doses, but it
   can get quite complicated as the configuration matures.
+
 *$Id$*
diff --git a/documentation/puppetd-executable-reference.page b/documentation/puppetd-executable-reference.page
index 9bb5e8581..eb344249d 100644
--- a/documentation/puppetd-executable-reference.page
+++ b/documentation/puppetd-executable-reference.page
@@ -343,6 +343,6 @@ argument is approprite or not.
 
 ----------------
 
+*$Id$*
 
 *This page autogenerated on Fri Jun 16 14:45:05 PDT 2006*
-*$Id$*
diff --git a/documentation/rails-puppet-manager.page b/documentation/rails-puppet-manager.page
index 8478455a7..dda8295d5 100644
--- a/documentation/rails-puppet-manager.page
+++ b/documentation/rails-puppet-manager.page
@@ -66,4 +66,5 @@ want to look at users; this would be your URL:
 http://puppet.domain.com/remote/culain/user/list
 
 Replace as appropriate for your site.
+
 *$Id$*
diff --git a/documentation/security.page b/documentation/security.page
index d5f7af8fe..9e7c52e9c 100644
--- a/documentation/security.page
+++ b/documentation/security.page
@@ -30,7 +30,7 @@ with the certificate request.  If the server has ``autosign`` turned on (which
 is not necessarily recommended), then the autosign configuration file (which
 defaults to ``/etc/puppet/autosign.conf``) is checked for whether the client's
 name matches any contents.  For instance, take the following configuration
-file::
+file:
     
     hostname.domain.com
     *.secure.domain.com
@@ -60,4 +60,5 @@ system-wide security hooks prior to the 1.0 release, but the certificate
 authentication already provides significant security.
 
 Recommendations on approaches are heartily recommended.
+
 *$Id$*
diff --git a/documentation/structures.page b/documentation/structures.page
index ec449482a..74cff0c68 100644
--- a/documentation/structures.page
+++ b/documentation/structures.page
@@ -10,7 +10,7 @@ For futher documentation, visit the [Puppet homepage](/projects/puppet).
 
 The basic unit of configuration in Puppet are ``types``.  Types model objects
 on the computer being managed, and each builtin type has attributes that
-determine the final type configuration::
+determine the final type configuration:
 
     file { "/etc/passwd": owner => root, mode => 644 } 
     package { apache: install => true }
@@ -35,7 +35,7 @@ by preceding them with the ``$`` character.
 Once assigned, variables cannot be reassigned. However,
 within a sub-scope a new assignment can be made for a
 variable name for that sub-scope and any further 
-sub-scopes created within it::
+sub-scopes created within it:
   
     $x = foo
     $y = bar
@@ -50,7 +50,7 @@ and classes at the current scope.  Currently files are only searched for
 within the same directory as the file doing the importing.
 
 Files can also be imported using globbing, as implemented by
-Ruby's ``Dir.glob`` method::
+Ruby's ``Dir.glob`` method:
 
     import "classes/*"
     import "packages/[a-z]*"
@@ -64,7 +64,7 @@ own scope but currently does not.
 
 Once assigned, variables cannot be reassigned within the same scope. However,
 within a sub-scope a new assignment can be made for a variable name for that
-sub-scope and any further scopes created within it::
+sub-scope and any further scopes created within it:
 
     $var = value
 
@@ -75,7 +75,7 @@ sub-scope and any further scopes created within it::
 
 Service and class definitions are scoped just as variable assignments are.
 Functions defined and Classes created within a scope will not be available
-outside the scope in which they are created::
+outside the scope in which they are created:
 
     define testing {
         file { "/etc/passwd": owner => root }
@@ -89,7 +89,7 @@ outside the scope in which they are created::
     }
 
 The evaluation by Puppet of following example would be result in the copying
-of ``/file_repository/test-httpd.conf`` to ``/etc/httpd/conf/httpd.conf``::
+of ``/file_repository/test-httpd.conf`` to ``/etc/httpd/conf/httpd.conf``:
  
     $filename = "/etc/apache/httpd.conf"
 
@@ -113,7 +113,7 @@ Definition of fuctions allows the composition of lower level types into higher
 level types.
 
 Parameters of defined functions can be referenced within the definition scope,
-similarly to variables, by preceding their names with the ``$`` character::
+similarly to variables, by preceding their names with the ``$`` character:
 
     define svnserve(source, path, user = false, password = false) {
         file { $path:
@@ -197,7 +197,7 @@ variables and selectors:
 ## Subclassing
 
 The primary benefit of using subclasses instead of just including the parent
-class is that the subclass can override elements in the parent class::
+class is that the subclass can override elements in the parent class:
 
     class unix {
         file { "/etc/sudoers":
@@ -227,7 +227,7 @@ argument or setting).  This means other tools can easily read in the classes
 that Puppet sets and use them for their own logic.
 
 There is also (as of 0.15.4) a new command to set arbitrary classes that do
-not have any code associated with them::
+not have any code associated with them:
 
     class freebsd {
         tag unix, bsd
@@ -239,7 +239,7 @@ not have any code associated with them::
 
 These classes will then be written to the classes.txt file like all others,
 even though there is no code associated with them.  The syntax is just like
-``include``, so you can use variables, also::
+``include``, so you can use variables, also:
 
     tag $operatingsystem
 
@@ -252,7 +252,7 @@ default they are looked for by ``puppetmasterd`` but not by ``puppet``.  See
 the documentation for each to enable or disable them.
 
 Any code outside of a node definition will be applied to all nodes, while any
-code inside will only apply to the specified node or nodes::
+code inside will only apply to the specified node or nodes:
 
     class webserver { ... }
     class dbserver { ... }
@@ -266,7 +266,7 @@ code inside will only apply to the specified node or nodes::
         include dbserver
     }
 
-Nodes can also inherit from other nodes, so it's easy to apply defaults::
+Nodes can also inherit from other nodes, so it's easy to apply defaults:
 
     node base {
         include $operatingsystem
@@ -281,7 +281,7 @@ Nodes can also inherit from other nodes, so it's easy to apply defaults::
 Puppet currently supports two types of conditionals: in-statement and around
 statements.  We call the in-statement conditionals ``selectors``, as they are
 essentially a select-style operator, which support the use of ``default`` to
-specify a default value::
+specify a default value:
 
     define testing(os) {
         owner = $os ? {
@@ -295,7 +295,7 @@ specify a default value::
 
 
 The ``case`` statement provides the ability to conditionally apply
-types::
+types:
 
     case $operatingsystem {
         sunos:      { solaris {} } # apply the solaris class
@@ -313,4 +313,5 @@ words like ``true``, ``define``, ``inherits``, and ``class`` are all reserved.
 
 Puppet supports sh-style comments; they can either be on their own line or at
 the end of a line (see the Conditionals example above).
+
 *$Id$*
diff --git a/documentation/testing.page b/documentation/testing.page
index 401e11bf6..3fd39f2ab 100644
--- a/documentation/testing.page
+++ b/documentation/testing.page
@@ -16,22 +16,22 @@ I often use my local Subversion sandbox for testing (i.e., I have my Puppet
 configuration stored in Subversion and checked out in my home directory, and I
 just test Puppet directly against this configuration).  Normally Puppet would
 make the configuration directory for you, but the server needs the ``site.pp``
-to exist, so you need to create the ``manifests`` subdirectory::
+to exist, so you need to create the ``manifests`` subdirectory:
 
     $ mkdir -p /var/tmp/puppet/manifests
     $ vi /var/tmp/puppet/manifests/site.pp
     <create file>
 
-Alternatively, you can just specify the manifest itself::
+Alternatively, you can just specify the manifest itself:
 
     $ sudo puppetmasterd --verbose --manifest ~/svn/puppet/manifests/site.pp
     
 I also always at least run the daemons in verbose mode while testing.  First
-start the central daemon::
+start the central daemon:
 
     $ sudo puppetmasterd --verbose --confdir /var/tmp/puppet
 
-By default, ``puppetmasterd`` looks for node definitions along these lines::
+By default, ``puppetmasterd`` looks for node definitions along these lines:
 
     node mymachine {
         include $operatingsystem
@@ -46,7 +46,7 @@ then you should create the config without nodes and use the ``--nonodes``
 argument.
 
 Once you have the manifest, start the client, pointing it at the local server,
-running in noop mode the first time::
+running in noop mode the first time:
 
     $ sudo puppetd --verbose --confdir /var/tmp/puppet --server localhost --noop --onetime
 
@@ -74,7 +74,7 @@ Also, you can narrow down what portion of the configuration you are testing by
 using '--tag'.  For instance, say you are running this on a machine that is an
 ldapserver, namedserver, and webserver, and you're adding ntpserver to the
 list of classes being evaluated.  Rather than sitting through the entire
-config every run, just apply the ntpserver elements::
+config every run, just apply the ntpserver elements:
 
     $ sudo puppet --server localhost --test --tag ntpserver