doc: Clean up more documentation

Signed-off-by: Sol Jerome <solj@ices.utexas.edu>

git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@5721 ce84e21b-d406-0410-9b95-82705330c041

11 files changed, 339 insertions, 177 deletions

diff --git a/doc/server/configurationentries.txt b/doc/server/configurationentries.txt
new file mode 100644
index 000000000..d4a1407d2
--- /dev/null
+++ b/doc/server/configurationentries.txt
@@ -0,0 +1,62 @@
+.. -*- mode: rst -*-
+
+.. _server-configurationentries:
+
+Configuration Entries
+---------------------
+
+This page describes the names and semantics of each of the configuration
+entries used by Bcfg2.
+
+Common non-POSIX entries
+^^^^^^^^^^^^^^^^^^^^^^^^
+
++-------------+---------------------+-----------------------------+
+| TagName     | Description         | Attributes                  |
++=============+=====================+=============================+
+| Action      | Command             | name, command, when, timing |
++-------------+---------------------+-----------------------------+
+| Package     | Software Packages   | name, type, version, url    |
++-------------+---------------------+-----------------------------+
+| PostInstall | PostInstall command | name                        |
++-------------+---------------------+-----------------------------+
+| Service     | System Services     | name, type, status, reload  |
++-------------+---------------------+-----------------------------+
+
+POSIX entries
+^^^^^^^^^^^^^
+
+In 1.0.0, there are new unified POSIX Path entries which prevent
+inconsistent configuration specifications of multiple entries for a given
+path. The following table describes the various types available for new
+**Path** entries.
+
++-------------+----------------------+-----------------+--------------------------+
+| Type        | Replacement/New      | Description     | Attributes               |
++=============+======================+=================+==========================+
+| device      | New                  | Create block,   | name, owner, group,      |
+|             |                      | character, and  | dev_type                 |
+|             |                      | fifo devices    | (block, char, fifo),     |
+|             |                      |                 | major/minor              |
+|             |                      |                 | (for block/char devices) |
++-------------+----------------------+-----------------+--------------------------+
+| directory   | Replaces Directory   | Directories     | name, owner, group,      |
+|             | entries              |                 | perms, prune             |
++-------------+----------------------+-----------------+--------------------------+
+| file        | Replaces ConfigFile  | Configuration   | name, owner, group,      |
+|             | entries              | File            | perms, encoding, empty   |
++-------------+----------------------+-----------------+--------------------------+
+| hardlink    | New                  | Create          | name, to                 |
+|             |                      | hardlinks       |                          |
++-------------+----------------------+-----------------+--------------------------+
+| nonexistent | New                  | Specify a path  | name                     |
+|             |                      | that should not |                          |
+|             |                      | exist           |                          |
++-------------+----------------------+-----------------+--------------------------+
+| permissions | Replaces Permissions | Permissions of  | name, owner,             |
+|             | entries              | POSIX entities  | group, perms             |
+|             |                      |                 |                          |
++-------------+----------------------+-----------------+--------------------------+
+| symlink     | Replaces SymLink     | SymLinks        | name, to                 |
+|             | entries              |                 |                          |
++-------------+----------------------+-----------------+--------------------------+
diff --git a/doc/server/plugins/generators/deps.txt b/doc/server/plugins/generators/deps.txt
index 9f704e905..e6f2c6a13 100644
--- a/doc/server/plugins/generators/deps.txt
+++ b/doc/server/plugins/generators/deps.txt
@@ -6,8 +6,10 @@
 Deps
 ====
 
-The Deps Plugin allows you to make a series of assertions like "Package X requires Package Y (and optionally also Package Z etc.)
-Note that only configuration entries, like Package, !ConfigFile, etc can be used. Groupings (like Bundle) are not supported.
+The Deps Plugin allows you to make a series of assertions like "Package
+X requires Package Y (and optionally also Package Z etc). Note that only
+configuration entries, like Package, Path, etc can be used. Groupings
+(like Bundle) are not supported.
 
 Here are some examples:
 
@@ -23,7 +25,9 @@ Deps/bcfg2.xml
         </Package>
     </Dependencies>
 
-This basically causes any configuration specification that includes Package bcfg2 to include python-lxml and isprelink, in a second base clause.
+This basically causes any configuration specification that includes
+Package bcfg2 to include python-lxml and isprelink, in a second base
+clause.
 
 Deps/bcfg2-server.xml
 =====================
@@ -47,4 +51,5 @@ Deps/bcfg2-server.xml
         </Package>
     </Dependencies>
 
-This states that the bcfg2-server package (it's a separate package on some distros) depends on a long list of other packages.
+This states that the bcfg2-server package (it's a separate package on
+some distros) depends on a long list of other packages.
diff --git a/doc/server/plugins/generators/hostbase.txt b/doc/server/plugins/generators/hostbase.txt
index 4cabf468a..6ba92a4e1 100644
--- a/doc/server/plugins/generators/hostbase.txt
+++ b/doc/server/plugins/generators/hostbase.txt
@@ -6,7 +6,9 @@
 Hostbase
 ========
 
-IP management system built on top of Bcfg2. It has four main parts: a django data model, a web frontend, command-line utilities, and a Bcfg2 plugin that generates dhcp, dns, and yp configuration files.
+IP management system built on top of Bcfg2. It has four main parts: a
+django data model, a web frontend, command-line utilities, and a Bcfg2
+plugin that generates dhcp, dns, and yp configuration files.
 
 Installation
 ============
@@ -14,23 +16,24 @@ Installation
 Overview
 --------
 
-Installation of Hostbase requires installation of a python module, configuration of database (mysql or postgres), and configuration of an Apache webserver with mod_python.  Hostbase was developed using MySQL, so this document is aimed at MySQL users.
+Installation of Hostbase requires installation of a python module,
+configuration of database (mysql or postgres), and configuration of an
+Apache webserver with mod_python. Hostbase was developed using MySQL,
+so this document is aimed at MySQL users.
 
 Prerequisites
 -------------
 
- * mysql
- * python-mysqldb
- * `Django <http://www.djangoproject.com>`_
+* `mysql`_
+* `python-mysqldb`_
+* `Django`_
 
-Install
--------
+.. _Django: http://www.djangoproject.com
+.. _python-mysqldb: http://mysql-python.sourceforge.net/MySQLdb.html
+.. _mysql: http://www.mysql.com/
 
-'''Install Hostbase python module:'''
-
-As of Bcfg2 v0.8.7; the Hostbase module has been renamed Bcfg2.Server.Hostbase, and is automatically installed; there is nothing to do in this step.
-
-'''Configure the database'''
+Configure the database
+----------------------
 
 Create the hostbase database and a user.  For MySQL users::
 
@@ -51,7 +54,8 @@ finish creating the database, from your ``path to
 python/Bcfg2/Server/Hostbase`` directory, run ``python manage.py
 syncdb`` to do all table creation.
 
-'''Configure the web interface'''
+Configure the web interface
+---------------------------
 
 Now it's possible to explore the Hostbase web interface.  For
 curiosity, you can run Django's built-in development server to take a
@@ -127,11 +131,22 @@ For production, you'll want to have this configured for Apache with mod_python.
     </VirtualHost>
 
 
-You'll need to copy the contents of ``Hostbase/media`` into ``/var/www/hostbase/site_media`` in this configuration to serve the correct css files.
+You'll need to copy the contents of ``Hostbase/media`` into
+``/var/www/hostbase/site_media`` in this configuration to serve the
+correct css files.
 
-'''Enable the Hostbase plugin'''
+Enable the Hostbase plugin
+--------------------------
 
-Now that the database is accessible and there is some data in it, you can enable the Hostbase plugin on your bcfg2 server to start generating some configuration files.  All that needs to be done is to add ``Hostbase`` to the end of the list of generators in your bcfg2.conf file.  To see what's being generated by Hostbase, fire up a bcfg2 development server: ``bcfg2-info``.  For more information on how to use the bcfg2 development server, type help at the prompt.  For our purposes, type ``debug``.  This will bring you to an interactive python prompt where you can access bcfg's core data.
+Now that the database is accessible and there is some data in it, you can
+enable the Hostbase plugin on your bcfg2 server to start generating some
+configuration files.  All that needs to be done is to add ``Hostbase``
+to the end of the list of generators in your bcfg2.conf file.  To see
+what's being generated by Hostbase, fire up a bcfg2 development server:
+``bcfg2-info``.  For more information on how to use the bcfg2 development
+server, type help at the prompt.  For our purposes, type ``debug``.
+This will bring you to an interactive python prompt where you can access
+bcfg's core data.
 
 .. code-block:: python
 
@@ -139,11 +154,16 @@ Now that the database is accessible and there is some data in it, you can enable
         print each
 
 
-The above loop will print out the name of each file that was generated by Hostbase.  You can see the contents of any of these by typing ``print bcore.plugins['Hostbase'].filedata[filename]``.
+The above loop will print out the name of each file that was generated
+by Hostbase.  You can see the contents of any of these by typing ``print
+bcore.plugins['Hostbase'].filedata[filename]``.
 
-'''Create a bundle'''
+Create a bundle
+---------------
 
-Bcfg2 needs a way to distribute the files generated by Hostbase.  We'll do this with a bundle.  In bcfg's ``Bundler`` directory, touch ``hostbase.xml``.
+Bcfg2 needs a way to distribute the files generated by Hostbase.
+We'll do this with a bundle.  In bcfg's ``Bundler`` directory, touch
+``hostbase.xml``.
 
 .. code-block:: xml
 
@@ -152,17 +172,27 @@ Bcfg2 needs a way to distribute the files generated by Hostbase.  We'll do this
        <Package name='bind9'/>
        <Service name='dhcp3-server'/>
        <Service name='bind9'/>
-       <ConfigFile name='/etc/dhcp3/dhcpd.conf'/>
-       <ConfigFile name='/etc/bind/[your domain]'/>
-       <ConfigFile name='/etc/bind/xxx.xxx.xxx.rev'/>
+       <Path name='/etc/dhcp3/dhcpd.conf'/>
+       <Path name='/etc/bind/[your domain]'/>
+       <Path name='/etc/bind/xxx.xxx.xxx.rev'/>
     </Bundle>
 
-The above example is a bundle that will deliver both dhcp and dns files.  This can be trivially split into separate bundles.  It is planned that Hostbase will eventually be able to generate the list of ``ConfigFiles`` in its bundles automatically.
+The above example is a bundle that will deliver both dhcp and dns files.
+This can be trivially split into separate bundles.  It is planned that
+Hostbase will eventually be able to generate the list of ``Paths``
+in its bundles automatically.
 
+Do a Hostbase push
+------------------
 
-'''Do a Hostbase push'''
-
-You'll want to be able to trigger the Hostbase plugin to rebuild it's config files and push them out when data has been modified in the database.  This can be done through and XMLRPC function available from the Bcfg2 server.  From a client that is configured to receive one or more hostbase bundles, you'll need to first edit your ``python/site-packages/Bcfg2/Client/Proxy.py`` file.  Add ``'Hostbase.rebuildState'`` to the list of methods in the bcfg2 client proxy object.  The modified list is shown below:
+You'll want to be able to trigger the Hostbase plugin to rebuild
+it's config files and push them out when data has been modified
+in the database.  This can be done through and XMLRPC function
+available from the Bcfg2 server.  From a client that is configured
+to receive one or more hostbase bundles, you'll need to first
+edit your ``python/site-packages/Bcfg2/Client/Proxy.py`` file.
+Add ``'Hostbase.rebuildState'`` to the list of methods in the bcfg2
+client proxy object.  The modified list is shown below:
 
 .. code-block:: python
 
@@ -171,8 +201,10 @@ You'll want to be able to trigger the Hostbase plugin to rebuild it's config fil
         name = 'bcfg2'
         methods = ['AssertProfile', 'GetConfig', 'GetProbes', 'RecvProbeData', 'RecvStats', 'Hostbase.rebuildState']
 
-Now copy the file ``hostbasepush.py`` from ``bcfg2/tools`` in the bcfg2 source to your machine.  When this command is run as root, it triggers the Hostbase to rebuild it's files, then runs the bcfg2 client on your local machine to grab the new configs.
-
+Now copy the file ``hostbasepush.py`` from ``bcfg2/tools`` in the bcfg2
+source to your machine.  When this command is run as root, it triggers
+the Hostbase to rebuild it's files, then runs the bcfg2 client on your
+local machine to grab the new configs.
 
 Authentication
 ==============
@@ -180,11 +212,15 @@ Authentication
 Edit Django settings
 --------------------
 
-Django allows for custom authentication backends to its login procedure.  Hostbase has an NIS authentication backend that verifies a user to be in the unix group allowed to modify Hostbase.
+Django allows for custom authentication backends to its login procedure.
+Hostbase has an NIS authentication backend that verifies a user to be
+in the unix group allowed to modify Hostbase.
 
 To enable this feature:
  * first edit your ``Hostbase/settings.py`` file and uncomment the line ``'Hostbase.backends.NISBackend',`` in the list of ``AUTHENTICATION_BACKENDS``
  * enter the name of the unix group you want to give access to Hostbase in the ``AUTHORIZED_GROUP`` variable
  * in your ``Hostbase/hostbase/views.py`` file at the very bottom, uncomment the block(s) of lines that give you the desired level of access
 
-Hostbase will now direct the user to a login page if he or she is not authorized to view a certain page.  Users should log in with their regular Unix username and password.
+Hostbase will now direct the user to a login page if he or she is not
+authorized to view a certain page.  Users should log in with their
+regular Unix username and password.
diff --git a/doc/server/plugins/generators/nagiosgen.txt b/doc/server/plugins/generators/nagiosgen.txt
index 23aeebd05..0815aab99 100644
--- a/doc/server/plugins/generators/nagiosgen.txt
+++ b/doc/server/plugins/generators/nagiosgen.txt
@@ -125,10 +125,10 @@ Create a nagios bcfg2 bundle /var/lib/bcfg2/Bundler/nagios.xml
 .. code-block:: xml
 
     <Bundle name='nagios' version='2.0'>
-      <ConfigFile name='/etc/nagiosgen.status'/>
+      <Path name='/etc/nagiosgen.status'/>
       <Group name='rh'>
         <Group name='nagios-server'>
-          <ConfigFile name='/etc/nagios/nagiosgen.cfg'/>
+          <Path name='/etc/nagios/nagiosgen.cfg'/>
           <Package name='libtool-libs'/>
           <Package name='nagios'/>
           <Package name='nagios-www'/>
@@ -137,7 +137,7 @@ Create a nagios bcfg2 bundle /var/lib/bcfg2/Bundler/nagios.xml
       </Group>
       <Group name='debian-lenny'>
         <Group name='nagios-server'>
-          <ConfigFile name='/etc/nagios3/nagiosgen.cfg'
+          <Path name='/etc/nagios3/nagiosgen.cfg'
                       altsrc='/etc/nagios/nagiosgen.cfg'/>
           <Package name='nagios3'/>
           <Package name='nagios3-common'/>
diff --git a/doc/server/plugins/generators/sshbase.txt b/doc/server/plugins/generators/sshbase.txt
index 21d4117fa..3e4454fb8 100644
--- a/doc/server/plugins/generators/sshbase.txt
+++ b/doc/server/plugins/generators/sshbase.txt
@@ -6,33 +6,58 @@
 SSHbase
 =======
 
-SSHbase is a purpose build bcfg2 plugin for managing ssh host keys. It is responsible for making ssh keys persist beyond a client rebuild and building a proper ssh_known_hosts file, including a correct localhost record for the current system.
+SSHbase is a purpose build bcfg2 plugin for managing ssh host keys. It
+is responsible for making ssh keys persist beyond a client rebuild and
+building a proper ssh_known_hosts file, including a correct localhost
+record for the current system.
 
 It has two functions:
 
-* Generating new ssh keys -- When a client requests a dsa, rsa, or v1 key, and there is no existing key in the repository, one is generated.
-* Maintaining the ssh_known_hosts file -- all current known public keys (and extra public key stores) are integrated into a single ssh_known_hosts file, and a localhost record for the current client is added. The ssh_known_hosts file data is updated whenever any keys change, are added, or deleted.
+* Generating new ssh keys -- When a client requests a dsa, rsa, or v1 key,
+  and there is no existing key in the repository, one is generated.
+
+* Maintaining the ssh_known_hosts file -- all current known public
+  keys (and extra public key stores) are integrated into a single
+  ssh_known_hosts file, and a localhost record for the current client
+  is added. The ssh_known_hosts file data is updated whenever any keys
+  change, are added, or deleted.
 
 Interacting with SSHbase
 ========================
 
-* Pre-seeding with existing keys -- Currently existing keys will be overwritten by new, sshbase-managed ones by default. Pre-existing keys can be added to the repository by putting them in <repo>/SSHbase/<key filename>.H_<hostname>
-* Pre-seeding can also be performed using bcfg2-admin pull ConfigFile /name/of/ssh/key
-* Revoking existing keys -- deleting <repo>/SSHbase/\*.H_<hostname> will remove keys for an existing client.
+* Pre-seeding with existing keys -- Currently existing keys will be
+  overwritten by new, sshbase-managed ones by default. Pre-existing keys
+  can be added to the repository by putting them in <repo>/SSHbase/<key
+  filename>.H_<hostname>
+
+* Pre-seeding can also be performed using bcfg2-admin pull ConfigFile
+  /name/of/ssh/key
+
+* Revoking existing keys -- deleting <repo>/SSHbase/\*.H_<hostname>
+  will remove keys for an existing client.
 
 Aliases
 =======
 
-SSHbase has support for Aliases listed in clients.xml. The address for the entries are specified either through DNS (e.g. a CNAME), or via the address attribute to the Alias.
+SSHbase has support for Aliases listed in clients.xml. The address for
+the entries are specified either through DNS (e.g. a CNAME), or via the
+address attribute to the Alias.
 
 Getting started
 ===============
 
-#. Add SSHbase to the generators line (plugins line in 1.0 or greater) in /etc/bcfg2.conf and restart the server -- This enables the SSHbase plugin in the bcfg2 server.
-#. Add Path entries for /etc/ssh/ssh_known_hosts, and /etc/ssh/ssh_host_dsa_key, etc to a bundle or base.
+#. Add SSHbase to the **plugins** line in ``/etc/bcfg2.conf`` and
+   restart the server -- This enables the SSHbase plugin in the bcfg2
+   server.
+
+#. Add Path entries for ``/etc/ssh/ssh_known_hosts``, and
+   ``/etc/ssh/ssh_host_dsa_key``, etc to a bundle or base.
+
 #. Enjoy.
 
-At this point, SSHbase will generate new keys for any client without a recorded key in the repository, and will generate an ssh_known_hosts file appropriately.
+At this point, SSHbase will generate new keys for any client without
+a recorded key in the repository, and will generate an ssh_known_hosts
+file appropriately.
 
 Blog post
 =========
diff --git a/doc/unsorted/altsrc.txt b/doc/unsorted/altsrc.txt
index 248405ebc..251781d28 100644
--- a/doc/unsorted/altsrc.txt
+++ b/doc/unsorted/altsrc.txt
@@ -6,34 +6,52 @@
 Fun and Profit using altsrc
 ===========================
 
-Altsrc is a generic, bcfg2-server-side mechanism for performing configuration entry name remapping for the purpose of data binding.
+Altsrc is a generic, bcfg2-server-side mechanism for performing
+configuration entry name remapping for the purpose of data binding.
 
 Use Cases
 =========
 
-* Equivalent configuration entries on different architectures with different names
-* Mapping entries with the same name to different bind results in a configuration (two packages with the same name but different types)
-* A single configuration entry across multiple specifications (multi-plugin, or multi-repo)
+* Equivalent configuration entries on different architectures with
+  different names
+
+* Mapping entries with the same name to different bind results in a
+  configuration (two packages with the same name but different types)
+
+* A single configuration entry across multiple specifications
+  (multi-plugin, or multi-repo)
 
 Examples
 ========
 
-* Consider the case of /etc/hosts on linux and /etc/inet/hosts on solaris. These files contain the same data in the same format, and should typically be synchronized, however, exist in different locations. Classically, one would need to create one entry for each in Cfg or TCheetah and perform manual synchronization. Or, you could use symlinks and pray. Altsrc is driven from the bundle side. For example:
+* Consider the case of /etc/hosts on linux and ``/etc/inet/hosts`` on
+  solaris. These files contain the same data in the same format,
+  and should typically be synchronized, however, exist in different
+  locations. Classically, one would need to create one entry for each in
+  Cfg or TCheetah and perform manual synchronization. Or, you could use
+  symlinks and pray. Altsrc is driven from the bundle side. For example:
 
   .. code-block:: xml
 
       <Bundle name='netinfo'>
          <Group name='solaris'>
-           <ConfigFile name='/etc/inet/hosts' altsrc='/etc/hosts'/>
+           <Path name='/etc/inet/hosts' altsrc='/etc/hosts'/>
          </Group>
          <Group name='linux'>
-           <ConfigFile name='/etc/hosts'/>
+           <Path name='/etc/hosts'/>
          </Group>
       </Bundle>
 
-  In this case, when a solaris host gets the 'netinfo' bundle, it will get the first !ConfigFile entry, which includes an altsrc parameter. This will cause the server to bind the entry as if it were a !ConfigFile called '/etc/hosts'. This configuration entry is still called '/etc/inet/hosts', and is installed as such.
+  In this case, when a solaris host gets the 'netinfo' bundle, it will
+  get the first Path entry, which includes an altsrc parameter. This
+  will cause the server to bind the entry as if it were a Path
+  called ``/etc/hosts``. This configuration entry is still called
+  ``/etc/inet/hosts``, and is installed as such.
 
-* On encap systems, frequently multiple packages of the same name, but of different types will exist. For example, there might be an openssl encap package, and an openssl rpm package. This can be dealt with using a bundle like:
+* On encap systems, frequently multiple packages of the same name, but
+  of different types will exist. For example, there might be an openssl
+  encap package, and an openssl rpm package. This can be dealt with
+  using a bundle like:
 
   .. code-block:: xml
 
@@ -42,30 +60,43 @@ Examples
          <Package name='openssl' altsrc='openssl-rpm'/>
       </Bundle>
 
-  This bundle will bind data for the packages "openssl-encap" and "openssl-rpm", but will be delivered to the client with both packages named "openssl" with different types.
+  This bundle will bind data for the packages "openssl-encap" and
+  "openssl-rpm", but will be delivered to the client with both packages
+  named "openssl" with different types.
 
-* Finally, consider the case where there exist complicated, but completely independent specifications for the same configuration entry but different groups of clients. The following bundle will allow the use of two different TCheetah templates /etc/firewall-rules-external and /etc/firewall-rules-internal for different clients based on their group membership.
+* Finally, consider the case where there exist complicated, but
+  completely independent specifications for the same configuration entry
+  but different groups of clients. The following bundle will allow the use
+  of two different TCheetah templates ``/etc/firewall-rules-external``
+  and ``/etc/firewall-rules-internal`` for different clients based on
+  their group membership.
 
   .. code-block:: xml
 
       <Bundle name='firewall'>
          ...
          <Group name='conduit'>
-           <ConfigFile name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/>
+           <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/>
          </Group>
          <Group name='internal'>
-           <ConfigFile name='/etc/firewall-rules' altsrc='/etc/firewall-rules-internal'/>
+           <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-internal'/>
          </Group>
       </Bundle>
 
-* Consider the case where a variety of files can be constructed by a single template (TCheetah or TGenshi). It would be possible to copy this template into the proper location for each file, but that requires proper synchronization upon modification and knowing up front what the files will all be called. Instead, the following bundle allows the use of a single template for all proper config file instances.
+* Consider the case where a variety of files can be constructed by a
+  single template (TCheetah or TGenshi). It would be possible to copy
+  this template into the proper location for each file, but that requires
+  proper synchronization upon modification and knowing up front what
+  the files will all be called. Instead, the following bundle allows
+  the use of a single template for all proper config file instances.
 
   .. code-block:: xml
 
       <Bundle name='netconfig'>
-        <ConfigFile name='/etc/sysconfig/network-scripts/ifcfg-eth0' altsrc='/etc/ifcfg-template'/>
-        <ConfigFile name='/etc/sysconfig/network-scripts/ifcfg-eth1' altsrc='/etc/ifcfg-template'/>
-        <ConfigFile name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/>
+        <Path name='/etc/sysconfig/network-scripts/ifcfg-eth0' altsrc='/etc/ifcfg-template'/>
+        <Path name='/etc/sysconfig/network-scripts/ifcfg-eth1' altsrc='/etc/ifcfg-template'/>
+        <Path name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/>
       </Bundle>
 
-  altsrc can be used as a parameter for any entry type, and can be used in any structure, including Bundler, Base, and SGenshi.
+  altsrc can be used as a parameter for any entry type, and can be used
+  in any structure, including Bundler and Base.
diff --git a/doc/unsorted/annotated_examples.txt b/doc/unsorted/annotated_examples.txt
index 99c6f774c..b5b7e6b4e 100644
--- a/doc/unsorted/annotated_examples.txt
+++ b/doc/unsorted/annotated_examples.txt
@@ -11,7 +11,8 @@ ntp example
 
 Author: Jason Pepas 
 
-Here is a series of example configurations for bcfg2, each introducing another layer of functionality.  
+Here is a series of example configurations for bcfg2, each introducing
+another layer of functionality.
 
 * After each change, run 'bcfg-repo-validate -v'.  
 * Run the server with 'bcfg2-server -v'.  
@@ -20,7 +21,8 @@ Here is a series of example configurations for bcfg2, each introducing another l
 package only
 ------------
 
-Our example starts with the bare minimum configuration setup.  We have a client, a profile group, a list of packages, and a base configuration.
+Our example starts with the bare minimum configuration setup.  We have
+a client, a profile group, a list of packages, and a base configuration.
 
 ::
 
@@ -77,7 +79,7 @@ Setup an etc directory structure, and add it to the base.::
     <Group name='fedora'>
     <Package name='ntp'/>
     <Service name='ntpd'/>
-    <ConfigFile name='/etc/ntp.conf'/>
+    <Path name='/etc/ntp.conf'/>
     </Group>
     </Base>
 
@@ -86,10 +88,10 @@ create a bundle
 
 The above configuration layout works fine for a single service, but
 that method of organization would quickly become a nightmare as you
-approach the number of packages, services, and config files required
-to represent a fully configured host.  Bundles allow the grouping of
-related configuration entries that are used to provide a single
-service. This is done for several reasons:
+approach the number of packages, services, and config files required to
+represent a fully configured host.  Bundles allow the grouping of related
+configuration entries that are used to provide a single service. This
+is done for several reasons:
 
 * Grouping related things in one place makes it easier to add those
   entries for a multiple groups of clients
@@ -102,20 +104,20 @@ service. This is done for several reasons:
   entity in that bundle is modified. This ensures that new
   configuration files and software are used after installation.
 
-The config file, package, and
-service are really all related components describing the idea of an
-ntp client, so they should be logically grouped together.  We use a
-bundle to accomplish this.::
+The config file, package, and service are really all related components
+describing the idea of an ntp client, so they should be logically
+grouped together.  We use a bundle to accomplish this.::
 
     # cat Bundler/ntp.xml
     <Bundle name='ntp' version='2.0'>
     <Package name='ntp'/>
     <Service name='ntpd'/>
-    <ConfigFile name='/etc/ntp.conf'/>
+    <Path name='/etc/ntp.conf'/>
     </Bundle>
 
 After this bundle is created, it must be associated with a group (or
-groups). Add a bundle child element to the group(s) which should install this bundle.::
+groups). Add a bundle child element to the group(s) which should install
+this bundle.::
 
 
     # cat Metadata/groups.xml
@@ -146,8 +148,8 @@ I added a new bundle:
 .. code-block: xml
 
     <Bundle name="mysql-server" version="3.0">
-       <ConfigFile name="/root/bcfg2-install/mysql/users.sh"/>
-       <ConfigFile name="/root/bcfg2-install/mysql/users.sql"/>
+       <Path name="/root/bcfg2-install/mysql/users.sh"/>
+       <Path name="/root/bcfg2-install/mysql/users.sql"/>
        <PostInstall name="/root/bcfg2-install/mysql/users.sh"/>
        <Package name="mysql-server-4.1"/>
        <Service name="mysql"/>
@@ -162,14 +164,17 @@ The `users.sh` script looks like this:
     mysql --defaults-extra-file=/etc/mysql/debian.cnf mysql \
         < /root/bcfg2-install/mysql/users.sql
 
-On debian there is a user account in `/etc/mysql/debian.cnf` automatically created, but you could also (manually) create a user in the database that has enough permissions and add the login information in a file yourself. This file looks like this::
+On debian there is a user account in ``/etc/mysql/debian.cnf``
+automatically created, but you could also (manually) create a user in
+the database that has enough permissions and add the login information
+in a file yourself. This file looks like this::
 
     [client]
     host     = localhost
     user     = debian-sys-maint
     password = XXXXXXXXXX
 
-The `users.sql` looks like this::
+The ``users.sql`` looks like this::
 
     DELETE FROM db;
     INSERT INTO db VALUES ('localhost', 'phpmyadmin', 'pma', 'Y', 'Y',
diff --git a/doc/unsorted/bundler_examples.txt b/doc/unsorted/bundler_examples.txt
index 88db94f56..442e9ce28 100644
--- a/doc/unsorted/bundler_examples.txt
+++ b/doc/unsorted/bundler_examples.txt
@@ -99,4 +99,4 @@ Examples
         <Path name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/>
       </Bundle>
 
-  altsrc can be used as a parameter for any entry type, and can be used in any structure, including Bundler, Base, and SGenshi.
+  altsrc can be used as a parameter for any entry type, and can be used in any structure, including Bundler and Base.
diff --git a/doc/unsorted/configurationentries.txt b/doc/unsorted/configurationentries.txt
deleted file mode 100644
index a841d56c1..000000000
--- a/doc/unsorted/configurationentries.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _unsorted-configurationentries:
-
-=====================
-Configuration Entries
-=====================
-
-This page describes the names and semantics of each of the configuration entries used by Bcfg2.
-
-Common non-POSIX entries
-========================
-
-|| '''!TagName''' || '''Description''' || '''Attributes''' ||
-|| Action || Command || name, command, when, timing ||
-|| Package || Software Packages || name, type, version, url ||
-|| !PostInstall || !PostInstall command || name ||
-|| Service || System Services || name, type, status, reload ||
-
-Bcfg2 >= 1.0.0: New unified POSIX entries
-=========================================
-
-In 1.0.0, there are new unified POSIX Path entries which prevent inconsistent configuration specifications of multiple entries for a given path. The following table describes the various types available for new `Path` entries.
-
-|| '''Type''' || '''Replacement/New''' || '''Description''' || '''Attributes''' ||
-|| device || New || Create block, character, and fifo devices || name, dev_type (block, char, fifo), owner, group, major/minor (for block or char devices) ||
-|| directory || Replaces Directory entries || Directories || name, owner, group, perms, prune ||
-|| file || Replaces !ConfigFile entries || Configuration File || name, owner, group, perms, encoding, empty ||
-|| hardlink || New || Create hardlinks || name, to ||
-|| nonexistent || New || Specify a path that should not exist || name ||
-|| permissions || Replaces Permissions entries || Permissions of POSIX entities || name, owner, group, perms ||
-|| symlink || Replaces !SymLink entries || !SymLinks || name, to ||
diff --git a/doc/unsorted/index.txt b/doc/unsorted/index.txt
index 02f09d640..f01aee67e 100644
--- a/doc/unsorted/index.txt
+++ b/doc/unsorted/index.txt
@@ -17,13 +17,6 @@ list below.
 * `NewDynamicReports`
 * `NewDynamicReportsInstallation`
 * `Plugins/Actions`
-* `Plugins/Bundler/examples/kernel.xml`
-* `Plugins/Bundler/examples/moab.xml`
-* `Plugins/Bundler/examples/nagios.xml`
-* `Plugins/Bundler/examples/ntp.xml`
-* `Plugins/Bundler/examples/snmpd.xml`
-* `Plugins/Bundler/examples/torque.xml`
-* `Plugins/Bundler/examples/yp.xml`
 * `Plugins/Ohai`
 * `Plugins/Snapshots`
 * `Plugins/TGenshi/examples/bcfg2_cron`
diff --git a/doc/unsorted/writing_specification.txt b/doc/unsorted/writing_specification.txt
index 083065f76..9fe847298 100644
--- a/doc/unsorted/writing_specification.txt
+++ b/doc/unsorted/writing_specification.txt
@@ -12,40 +12,63 @@ Bcfg2 specifications are logically divided in to three areas:
 * Abstract
 * Literal
 
-The metadata portion of the configuration assigns a client to its profile group and to its non profle groups.  The profile group is assigned in Metadata/clients.xml and the non profile group assignments are in Metadata/groups.xml.
-
-The group memberships contained in the metadata are then used to constuct an abstract configuration for the client. An abstract configuration for a client identifies the configuration entities (packages, configuration files, service, etc) that a client requires, but it does not identify them explicitly. For instance an abstract configuration may identify that a client needs the bcfg2 package with
+The metadata portion of the configuration assigns a client to its profile
+group and to its non profle groups. The profile group is assigned
+in Metadata/clients.xml and the non profile group assignments are in
+Metadata/groups.xml.
+
+The group memberships contained in the metadata are then used to constuct
+an abstract configuration for the client. An abstract configuration for
+a client identifies the configuration entities (packages, configuration
+files, service, etc) that a client requires, but it does not identify
+them explicitly. For instance an abstract configuration may identify
+that a client needs the bcfg2 package with
 
 .. code-block:: xml
 
     <Package name=bcfg2/>
 
-but this does not explicitly identify that an RPM package version 0.9.2 should be loaded from http://rpm.repo.server/bcfg2-0.9.2-0.1.rpm.  The abstract configuration is defined in the xml configuration files for the Base and Bundles plugins.
+but this does not explicitly identify that an RPM package version
+0.9.2 should be loaded from http://rpm.repo.server/bcfg2-0.9.2-0.1.rpm.
+The abstract configuration is defined in the xml configuration files
+for the Base and Bundles plugins.
 
-A combination of a clients metadata (group memberships) and abstract configuration is then used to generate the clients literal configuration.  For instance the above abstract configuration entry may generate a literal configuration of
+A combination of a clients metadata (group memberships) and abstract
+configuration is then used to generate the clients literal configuration.
+For instance the above abstract configuration entry may generate a
+literal configuration of
 
 
 .. code-block:: xml
 
     <Package name='bcfg2' version='0.9.2-0.1' type='yum'/>
 
-A clients literal configuration is generated by a number of plugins that handle the different configuration entities.
+A clients literal configuration is generated by a number of plugins that
+handle the different configuration entities.
 
 .. image:: specification_overview.png
 
 Dynamic Groups
 ==============
 
-Dynamic groups are likewise complex, and are covered on their own [wiki:DynamicGroups page]
+Dynamic groups are likewise complex, and are covered on their own
+[wiki:DynamicGroups page]
 
 Abstract Configuration (Structures)
 ===================================
 
-A clients Abstract Configuration is the inventory of configuration entities that should be installed on a client.  Two plugins provide the basis for the abstract configuration, the Bundler and Base.
+A clients Abstract Configuration is the inventory of configuration
+entities that should be installed on a client. Two plugins provide the
+basis for the abstract configuration, the Bundler and Base.
 
-The plugin Bundler builds descriptions of interrelated configuration entities.  These are typically used for the representation of services, or other complex groups of entities.
+The plugin Bundler builds descriptions of interrelated configuration
+entities. These are typically used for the representation of services,
+or other complex groups of entities.
 
-The Base provides a laundry list of configuration entities that need to be installed on hosts.  These entities are independent from one another, and can be installed individually without worrying about the impact on other entities.
+The Base provides a laundry list of configuration entities that need to
+be installed on hosts. These entities are independent from one another,
+and can be installed individually without worrying about the impact on
+other entities.
 
 Usage of Groups in Base and Bundles
 -----------------------------------
@@ -67,57 +90,39 @@ Group membership maybe negated.  See "Writing Bundles" for an example.
 Configuration Entity Types
 --------------------------
 
-Entities in the abstract configuration (and correspondingly in the literal configuration) can have one of several types.  In the abstract configuration, each of these entities only has a tag and the name attribute set.
+Entities in the abstract configuration (and correspondingly in the
+literal configuration) can have one of several types. In the abstract
+configuration, each of these entities only has a tag and the name
+attribute set.
 
-The types of Configuration Entities that maybe assigned to the abstract configuration are as follows:
+The types of Configuration Entities that maybe assigned to the abstract
+configuration are as follows:
 
-|| '' '''Tag''' '' || '' '''Description''' '' ||
-|| Package || Software Package ||
-|| !ConfigFile || Configuration File ||
-|| Service  || Persistent system services and daemons ||
-|| Directory || File system Directories ||
-|| !SymLink  || Symbolic links ||
-|| Permissions || The permissions (not contents) of a POSIX path ||
-|| Action || Actions to be performed as part of a bundle installation ||
+.. include:: ../server/configurationentries.txt
 
 An example of each entity type is below.
 
 .. code-block:: xml
 
     <Package name='bcfg2'/>
-    <ConfigFile name='/etc/bcfg2.conf'/>
+    <Path name='/etc/bcfg2.conf'/>
     <Service name='ntpd'/>
-    <Directory name='/var/tmp'/>
-    <SymLink name='/dev/MAKEDEV'/>
-    <Permissions name='/etc/passwd'/>
     <Action name='action_name'/>
 
-Configuration Entity Name Attribute
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-With the exception of the Action Entity type, the value of the configuration entity name attribute is not arbitary.  It must map to entities of the same type in the Literal Configuration, which in turn map to physical entities on the client.
-
-For the most part the physical entity being mapped to is intuitive and are listed below.
-
-|| '' '''Tag''' '' || '' '''Description''' '' ||
-|| Package || name of the software package ||
-|| !ConfigFile || Full absolute path of the configuration file ||
-|| Service  || Name of the init script for the service which may not be that same as the name of the daemon started or the package name ||
-|| Directory || Full absolute path of the directories ||
-|| !SymLink  || Full absolute path of the symbolic linkss ||
-|| Permissions || Full absolute path of the file or directory ||
-|| Action || Arbitary name ||
-
 Writing Bundles
 ---------------
 
-Bundles consist of a set of configuration entities.  These entities are grouped together due to a configuration-time interdependency.  Basic services tend to be the simplest example of these.  They normally consist of
+Bundles consist of a set of configuration entities. These entities
+are grouped together due to a configuration-time interdependency.
+Basic services tend to be the simplest example of these. They normally
+consist of
 
 * some software package(s)
 * some configuration files
 * an indication that some service should be activated
 
-If any of these pieces are installed or updated, all should be rechecked and any associated services should be restarted.
+If any of these pieces are installed or updated, all should be rechecked
+and any associated services should be restarted.
 
 All files in the Bundles/ subdirectory of the repository are processed.
 Each bundle must be defined in its own file and the filename must be the
@@ -142,11 +147,22 @@ same as the bundle name with a .xml suffix.::
     atftp.xml
     ....
 
-Groups can be used inside of bundles to differentiate which entries particular clients will receive.  This is useful for the case where entries are named differently across systems; for example, one linux distro may have a package called openssh while another uses the name ssh.  Configuration entries nested inside of Group elements only apply to clients who are a member of those groups; multiply nested groups must all apply.
+Groups can be used inside of bundles to differentiate which entries
+particular clients will receive. This is useful for the case where
+entries are named differently across systems; for example, one linux
+distro may have a package called openssh while another uses the name ssh.
+Configuration entries nested inside of Group elements only apply to
+clients who are a member of those groups; multiply nested groups must
+all apply.
 
-Also, groups may be negated; entries included in such groups will only apply to clients who are not a member of said group.
+Also, groups may be negated; entries included in such groups will only
+apply to clients who are not a member of said group.
 
-When packages in a bundle are verified by the client toolset, the !ConfigFiles included in the same bundle are taken into consideration.  That is, a package will not fail verification from a bcfg2 perspective if the package verification only failed because of configuration files that are defined in the same bundle.
+When packages in a bundle are verified by the client toolset, the Paths
+included in the same bundle are taken into consideration.  That is,
+a package will not fail verification from a bcfg2 perspective if the
+package verification only failed because of configuration files that
+are defined in the same bundle.
 
 The following is an annotated copy of a bundle:
 
@@ -180,7 +196,15 @@ The following is an annotated copy of a bundle:
       </Group>
     </Bundle>
 
-In this bundle, most of the entries are common to all systems.  Clients in group "deb" get one extra package and service, while clients in group "rpm" get two extra packages and an extra service.  In addition, clients in group "fedora" and group "rpm" get one extra package entries, unless they are not in the fc4 group, in which case, they get an extra package.  Notice that this file doesn't describe which versions of these entries that clients should get, only that they should get them.  (Admittedly, this example is slightly contrived, but demonstrates how group entries can be used in bundles)
+In this bundle, most of the entries are common to all systems. Clients
+in group "deb" get one extra package and service, while clients in group
+"rpm" get two extra packages and an extra service. In addition, clients
+in group "fedora" and group "rpm" get one extra package entries, unless
+they are not in the fc4 group, in which case, they get an extra package.
+Notice that this file doesn't describe which versions of these entries
+that clients should get, only that they should get them. (Admittedly,
+this example is slightly contrived, but demonstrates how group entries
+can be used in bundles)
 
 || '' '''Group ''' '' || '' '''Entry ''' '' ||
 || all  || /etc/ssh/ssh_host_dsa_key  ||
@@ -211,12 +235,14 @@ The Bundle Tag has the following possible attributes:
 || origin || URL of master version (for common repo) || String ||
 || revision || Master version control revision || String ||
 
-As mentioned above the Configuration Entity Tags may only have the name attribute in Bundle definitions.
+As mentioned above the Configuration Entity Tags may only have the name
+attribute in Bundle definitions.
 
 Abstract Group Tag
 ^^^^^^^^^^^^^^^^^^
 
-In the Abstract Configuration plugins (Base and Bundle) the Group Tag may have the following attributes:
+In the Abstract Configuration plugins (Base and Bundle) the Group Tag
+may have the following attributes:
 
 || '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
 || name || Name of group. || String ||
@@ -260,32 +286,42 @@ configuration.::
         </Group>
     </Base>
 
-The format of the Base files are similar to those used by the Bundler.  The majority of the elements are usually Packages, but !ConfigFiles, Directories, Services, Permissions,  and !SymLinks may all be defined.  A partial example is below:
+The format of the Base files are similar to those used by the Bundler.
+The majority of the elements are usually Packages, but Paths of any type
+may all be defined. A partial example is below:
 
 Base Tag
 ^^^^^^^^
 
 The Base Tag has no attributes
 
-As mentioned above the Configuration Entity Tags contained in a Base definition may only have the name attribute in Base definitions.
+As mentioned above the Configuration Entity Tags contained in a Base
+definition may only have the name attribute in Base definitions.
 
 Abstract Group Tag
 ^^^^^^^^^^^^^^^^^^
 
-In the Abstract Configuration plugins (Base and Bundle) the Group Tag may have the following attributes:
+In the Abstract Configuration plugins (Base and Bundle) the Group Tag
+may have the following attributes:
 
 || '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
 || name || Name of group. || String ||
 || negate || Negate the group association (is not a member of) || (True|False*) ||
 
-An abstract group may contain any of the Configuration Entity types and other groups.
+An abstract group may contain any of the Configuration Entity types and
+other groups.
 
 Literal Configuration (Generators)
 ==================================
 
-A Generator is a bcfg2 piece of code that is run to generate the literal configuration for a host using a combination of the hosts metadata and abstract configuration.
+A Generator is a bcfg2 piece of code that is run to generate the literal
+configuration for a host using a combination of the hosts metadata and
+abstract configuration.
 
-A Generator can take care of a particular configuration element.  Any time this element is requested by the client, the server dynamically generates it either by crunching data and creating new information or by reading a file off of disk and passes it down to the client for installation.
+A Generator can take care of a particular configuration element. Any time
+this element is requested by the client, the server dynamically generates
+it either by crunching data and creating new information or by reading
+a file off of disk and passes it down to the client for installation.
 
 Usage of Groups in Generators
 -----------------------------
@@ -302,7 +338,8 @@ Nested groups are conjunctive (logical and).::
     if client is a member of group1 and group2 then
         assign to abstract config
 
-How the groups are configured is specific to the plugin, but here are two common methods:
+How the groups are configured is specific to the plugin, but here are
+two common methods:
 
 * xml configuration file (Pkgmgr, Rules)
 * file name encoding (Cfg, TCheetah, SSHBase)