doc: Formatting fixes

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

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

12 files changed, 517 insertions, 170 deletions

diff --git a/doc/client/agent.txt b/doc/client/agent.txt
index 1a3b4b2eb..eec66964f 100644
--- a/doc/client/agent.txt
+++ b/doc/client/agent.txt
@@ -6,32 +6,48 @@
 Agent Functionality using SSH
 =============================
 
-The Bcfg2 agent code provides the ability to trigger a client update from the server using a secure mechanism that is restricted to running the bcfg2 client with the options the agent was started with. This same capability is provided by SSH keypairs, if properly configured. Setup is pretty easy:
-
-#. Create an ssh keypair that is to be used solely for triggering bcfg2 client runs. This key may or may not have a password associated with it; a keyphrase will make things more secure, but will require a person to enter the key passphrase, so it will not be usable automatically.::
-
-    $ ssh-keygen -t dsa -b 1024 -f /path/to/key -N ""
-    Generating public/private dsa key pair.
-    Your identification has been saved in /path/to/key.
-    Your public key has been saved in /path/to/key.pub.
-    The key fingerprint is:
-    aa:25:9b:a7:10:60:f3:eb:2b:ae:4b:1a:42:1b:63:5d desai@ubik
-
-#. Add this this public key to root's authorized_keys file, with several commands prepended to it::
-
-    command="/usr/sbin/bcfg2 -q <other options>",no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding,from="<bcfg2-server ipaddr>" <pub key>
-
-   This key is now only useful to call the bcfg2 client, from the bcfg2-server's ip address. If PermitRootLogin was set to no in sshd_config, you will need to set it to forced-commands-only. Adding a & to the end of the command will cause the command to immediately return. 
+The Bcfg2 agent code provides the ability to trigger a client update
+from the server using a secure mechanism that is restricted to running
+the bcfg2 client with the options the agent was started with. This same
+capability is provided by SSH keypairs, if properly configured. Setup
+is pretty easy:
+
+#. Create an ssh keypair that is to be used solely for triggering bcfg2
+   client runs. This key may or may not have a password associated with
+   it; a keyphrase will make things more secure, but will require a person
+   to enter the key passphrase, so it will not be usable automatically.::
+
+       $ ssh-keygen -t dsa -b 1024 -f /path/to/key -N ""
+       Generating public/private dsa key pair.
+       Your identification has been saved in /path/to/key.
+       Your public key has been saved in /path/to/key.pub.
+       The key fingerprint is:
+       aa:25:9b:a7:10:60:f3:eb:2b:ae:4b:1a:42:1b:63:5d desai@ubik
+
+#. Add this this public key to root's authorized_keys file, with several
+   commands prepended to it::
+
+       command="/usr/sbin/bcfg2 -q <other options>",no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding,from="<bcfg2-server ipaddr>" <pub key>
+
+   This key is now only useful to call the bcfg2 client, from the
+   bcfg2-server's ip address. If PermitRootLogin was set to no in
+   sshd_config, you will need to set it to forced-commands-only. Adding
+   a & to the end of the command will cause the command to immediately
+   return.
 
 #. Now, to cause a client to reconfigure, call::
 
-    $ ssh -i /path/to/key root@client /usr/sbin/bcfg2
+       $ ssh -i /path/to/key root@client /usr/sbin/bcfg2
 
-   Note that you will not be able to alter the command line options from the ones specified in authorized_keys in any way. Also, it is not needed that the invocation of bcfg2 in the ssh command match. The following will have the same result.::
+   Note that you will not be able to alter the command line options from
+   the ones specified in authorized_keys in any way. Also, it is not
+   needed that the invocation of bcfg2 in the ssh command match. The
+   following will have the same result.::
 
-    $ ssh -i /path/to/key root@client /bin/true
+       $ ssh -i /path/to/key root@client /bin/true
 
-   If a passphrase was used to create the keypair, then it will need to be entered here. 
+   If a passphrase was used to create the keypair, then it will need to
+   be entered here.
 
 See Also
 ========
diff --git a/doc/client/metadata.txt b/doc/client/metadata.txt
index 6675f59d7..2a19f3a1a 100644
--- a/doc/client/metadata.txt
+++ b/doc/client/metadata.txt
@@ -6,39 +6,88 @@
 Client Metadata
 ===============
 
-This page describes ClientMetadata objects. These are used to describe clients in terms of a variety of parameters, group memberships, and so forth.
+This page describes ClientMetadata objects. These are used to describe
+clients in terms of a variety of parameters, group memberships, and
+so forth.
 
 Construction
 ============
 
-ClientMetadata instances are constructed whenever the server needs to recognize a client. This occurs in every aspect of client server interaction:
+ClientMetadata instances are constructed whenever the server needs
+to recognize a client. This occurs in every aspect of client server
+interaction:
 
 * Probing
 * Configuration Generation
 * Statistics Upload
 
-This construction process spans several server plugins. The [wiki:Plugins/Metadata Metadata plugin] is responsible for initial instance creation, including the client hostname, profile, and basic group memberships. After this initial creation, Connector plugins (such as [wiki:Plugins/Probes Probes] or [wiki:Plugins/Properties Properties]) can add additional group memberships for clients. These memberships are merged into the instance; that is, the new group memberships are treated as if they were included in groups.xml. If any of these groups are defined in groups.xml, then groups included there are included in the ClientMetadata instance group list. At the end of this process, the ClientMetadata instance has its complete set of group memberships. At this point, each connector plugin has the opportunity to return an additional object which will be placed in an attribute corresponding to the Connector name. For example, the Probes plugin returns a dictionary of probe name to probe result mappings for the client. This dictionary is available as the "Probes" attribute. With this, ClientMetadata resolution is complete, and the ClientMetadata instance can be used by the rest of the system.
+This construction process spans several server plugins. The
+:ref:`server-plugins-grouping-metadata` is responsible for initial
+instance creation, including the client hostname, profile, and basic
+group memberships. After this initial creation, Connector plugins (such as
+:ref:`server-plugins-probes-index` or :ref:`server-plugins-properties`)
+can add additional group memberships for clients. These memberships
+are merged into the instance; that is, the new group memberships are
+treated as if they were included in groups.xml. If any of these groups
+are defined in groups.xml, then groups included there are included in
+the ClientMetadata instance group list. At the end of this process, the
+ClientMetadata instance has its complete set of group memberships. At this
+point, each connector plugin has the opportunity to return an additional
+object which will be placed in an attribute corresponding to the Connector
+name. For example, the Probes plugin returns a dictionary of probe name
+to probe result mappings for the client. This dictionary is available as
+the "Probes" attribute. With this, ClientMetadata resolution is complete,
+and the ClientMetadata instance can be used by the rest of the system.
 
 Contents
 ========
 
-ClientMetadata instances contain all of the information needed to differentiate clients from one another. This data includes:
+ClientMetadata instances contain all of the information needed to
+differentiate clients from one another. This data includes:
 
 * hostname
 * groups
 * profile group
 * address information (if specified)
 
-ClientMetadata instances also contain a query object. This can be used to query the metadata of other clients. Currently, several methods are supported. In this table, we refer to the instance as meta. Each of these is a function that must be called.
+ClientMetadata instances also contain a query object. This can be used
+to query the metadata of other clients. Currently, several methods are
+supported. In this table, we refer to the instance as meta. Each of
+these is a function that must be called.
 
-|| Name || Description || Return Type ||
-|| meta.query.names_by_groups([group list]) || Returns names of clients which are members of all groups || List of client names ||
-|| meta.query.names_by_profile(profile) || Returns names of clients which use profile group || List of client names ||
-|| meta.query.all_clients() || Returns names of all clients || List of client names ||
-|| meta.query.all_groups() || Returns names of all groups || List of group names ||
-|| meta.query.all() || Returns metadata for all clients || List of ClientMetadata instances ||
-|| meta.query.by_name(name) || Returns metadata for named client || ClientMetadata instance ||
-|| meta.query.by_groups([group list]) || Returns metadata for all members of all groups || List of ClientMetadata instances ||
-|| meta.query.by_profile(profile) || Returns metadata for all profile havers || List of ClientMetadata instances ||
++------------------------------------------+-------------------+----------------+
+| Name                                     | Description       | Return Type    |
++==========================================+===================+================+
+| meta.query.names_by_groups([group list]) | Returns names of  | List of        |
+|                                          | clients which are | client names   |
+|                                          | members of all    |                |
+|                                          | groups            |                |
++------------------------------------------+-------------------+----------------+
+| meta.query.names_by_profile(profile)     | Returns names of  | List of        |
+|                                          | clients which use | client names   |
+|                                          | profile group     |                |
++------------------------------------------+-------------------+----------------+
+| meta.query.all_clients()                 | Returns names of  | List of        |
+|                                          | all clients       | client names   |
++------------------------------------------+-------------------+----------------+
+| meta.query.all_groups()                  | Returns names of  | List of        |
+|                                          | all groups        | group names    |
++------------------------------------------+-------------------+----------------+
+| meta.query.all()                         | Returns metadata  | List of        |
+|                                          | for all clients   | ClientMetadata |
+|                                          |                   | instances      |
++------------------------------------------+-------------------+----------------+
+| meta.query.by_name(name)                 | Returns metadata  | ClientMetadata |
+|                                          | for named client  | instance       |
++------------------------------------------+-------------------+----------------+
+| meta.query.by_groups([group list])       | Returns metadata  | List of        |
+|                                          | for all members   | ClientMetadata |
+|                                          | of all groups     | instances      |
++------------------------------------------+-------------------+----------------+
+| meta.query.by_profile(profile)           | Returns metadata  | List of        |
+|                                          | for all profile   | ClientMetadata |
+|                                          | havers            | instances      |
++------------------------------------------+-------------------+----------------+
 
-In general, there is no substantial benefit to using name returning versions of the query functions; metadata resolution is (in general) fast.
+In general, there is no substantial benefit to using name returning
+versions of the query functions; metadata resolution is (in general) fast.
diff --git a/doc/client/paranoid.txt b/doc/client/paranoid.txt
index 1bf8c4fa5..8a597892e 100644
--- a/doc/client/paranoid.txt
+++ b/doc/client/paranoid.txt
@@ -16,13 +16,16 @@ administrator.
 How do I use it?
 ================
 
-#. In the Bcfg2 repository, put `paranoid='true'` in the `info.xml` file.
-#. On the client, create `/var/cache/bcfg2` (in 1.0, you can specify an alternate path in the [paranoid] section of /etc/bcfg2).
+#. In the Bcfg2 repository, put `paranoid='true'` in the ``info.xml``
+   file.
+#. On the client, create ``/var/cache/bcfg2`` (or specify an alternate
+   path in the [paranoid] section of /etc/bcfg2).
 #. On the client, run `bcfg2` with the `-P` option.
 
-This will save a copy of the replaced file in `/var/cache/bcfg2`, but
-it'll be named as the path to the file with /'s replaced by _'s. For
-example, the old `/etc/hosts` will be named `/var/cache/bcfg2/etc_hosts`.
+This will save a copy of the replaced file in ``/var/cache/bcfg2``,
+but it'll be named as the path to the file with /'s replaced
+by _'s. For example, the old `/etc/hosts` will be named
+``/var/cache/bcfg2/etc_hosts``.
 
 Extra configuration
 ===================
diff --git a/doc/client/tools/index.txt b/doc/client/tools/index.txt
index d845235f4..9d560ff6e 100644
--- a/doc/client/tools/index.txt
+++ b/doc/client/tools/index.txt
@@ -5,25 +5,40 @@
 Client Tool Drivers
 ===================
 
-Client tool drivers allow bcfg2 to execute configuration operations by interfacing with platform and distribution specific tools.
+Client tool drivers allow bcfg2 to execute configuration operations by
+interfacing with platform and distribution specific tools.
 
-Tool drivers handle any reconfiguration or verification operation. So far we have tools that primarily deal with packaging systems and service management. The POSIX tool also handles file system and permissions/groups operations.
+Tool drivers handle any reconfiguration or verification operation. So
+far we have tools that primarily deal with packaging systems and service
+management. The POSIX tool also handles file system and permissions/groups
+operations.
 
-To write your own tool driver, to handle a new packaging format, or new service architecture see WritingClientToolDrivers.
+To write your own tool driver, to handle a new packaging format, or new
+service architecture see WritingClientToolDrivers.
 
-When the bcfg2 client is run, it attempts to instantiate each of these drivers. The succeeding list of drivers are printed as a debug message after this process has completed. Drivers can supercede one another, for example, the Yum driver conflicts (and unloads) the RPM driver. This behavior can be overridden by running the bcfg2 client with the -D flag. This flag takes a colon delimited list of drivers to use on the system.
+When the bcfg2 client is run, it attempts to instantiate each of these
+drivers. The succeeding list of drivers are printed as a debug message
+after this process has completed. Drivers can supercede one another,
+for example, the Yum driver conflicts (and unloads) the RPM driver. This
+behavior can be overridden by running the bcfg2 client with the -D
+flag. This flag takes a colon delimited list of drivers to use on
+the system.
 
 Currently these are the tool drivers that are distributed with bcfg2:
 
 Action
 ------
 
-Pre and post-install tests and actions. This driver executes commands and supplies status information to the bcfg2 server via the statistics mechanism. It can also be used to prevent bundle installation when pre-conditions are not met. See the UsingActions page for more details.
+Pre and post-install tests and actions. This driver executes commands
+and supplies status information to the bcfg2 server via the statistics
+mechanism. It can also be used to prevent bundle installation when
+pre-conditions are not met. See the UsingActions page for more details.
 
 APT
 ---
 
-Debian Packages. This tool driver is used to handle packages on dpkg based systems and employs the "apt" executable.
+Debian Packages. This tool driver is used to handle packages on dpkg
+based systems and employs the "apt" executable.
 
 Blast
 -----
@@ -35,7 +50,11 @@ Chkconfig
 
 Tool to manage services (primarily on Redhat based distros).
 
-.. note:: Start and stop are standard arguments, but the one for reload isn't consistent across services. You can specify which argument to use with the `reload` property in Service tags. Example: `<Service name="ftp" reload="condrestart" status="on" type="chkconfig">`
+.. note:: Start and stop are standard arguments, but the one for reload
+          isn't consistent across services. You can specify which argument
+          to use with the `reload` property in Service tags. Example:
+          `<Service name="ftp" reload="condrestart" status="on"
+          type="chkconfig">`
 
 DebInit
 -------
@@ -55,12 +74,17 @@ FreeBSD Service Support. Only bundle updates will work.
 FreeBSDPackage
 --------------
 
-FreeBSD Packages. Verifies packages and their version numbers but can't install packages.
+FreeBSD Packages. Verifies packages and their version numbers but can't
+install packages.
 
 launchd
 -------
 
-Mac OS X Services. To use this tool, you must maintain a standard launch daemon .plist file in `/Library/LaunchDaemons/` (example ssh.plist) and setup a `<Service name="com.openssh.sshd" type="launchd" status="on" />` entry in your config to load or unload the service. Note the name is the ''Label'' specified inside of the .plist file
+Mac OS X Services. To use this tool, you must maintain a standard launch
+daemon .plist file in ``/Library/LaunchDaemons/`` (example ssh.plist) and
+setup a `<Service name="com.openssh.sshd" type="launchd" status="on" />`
+entry in your config to load or unload the service. Note the name is the
+''Label'' specified inside of the .plist file
 
 Portage
 -------
@@ -70,12 +94,14 @@ Support for Gentoo Packages.
 POSIX
 -----
 
-Files and Permissions are handled by the POSIX driver. Usage well documented other places.
+Files and Permissions are handled by the POSIX driver. Usage well
+documented other places.
 
 RcUpdate
 --------
 
-Uses the rc-update executable to manage services on distributions such as Gentoo.
+Uses the rc-update executable to manage services on distributions such
+as Gentoo.
 
 RPM
 ---
@@ -86,7 +112,9 @@ Executes rpm to manage packages most often on redhat based systems.
 RPMng
 -----
 
-Next-generation RPM tool, will be default in upcoming release. Handles RPM sublties like epoch and prelinking and 64-bit platforms better than RPM client tool. [wiki:ClientTools/RPMng RPMng/YUMng Documentation.]
+Next-generation RPM tool, will be default in upcoming release. Handles
+RPM sublties like epoch and prelinking and 64-bit platforms better than
+RPM client tool. :ref:`client-tools-yumng`
 
 SMF
 ---
@@ -113,4 +141,5 @@ Handles RPMs using the YUM package manager.
 YUMng
 -----
 
-Handles RPMs using the YUM package manager. Handles sublties better than the Yum client tool. [wiki:ClientTools/RPMng RPMng/YUMng Documentation.]
+Handles RPMs using the YUM package manager. Handles sublties better than
+the Yum client tool. :ref:`client-tools-yumng`
diff --git a/doc/client/tools/yumng.txt b/doc/client/tools/yumng.txt
index 178bba6ec..8e7ffa1eb 100644
--- a/doc/client/tools/yumng.txt
+++ b/doc/client/tools/yumng.txt
@@ -9,9 +9,12 @@ BCFG2 RPMng/YUMng Client Drivers
 Introduction
 ============
 
-The goal of this driver is to resolve the issues that exist with the RPM and Yum client tool drivers.
+The goal of this driver is to resolve the issues that exist with the
+RPM and Yum client tool drivers.
 
-For the most part, the issues are due to RPM being able to have multiple packages of the same name installed.  This is an issue on all Red Hat and SUSE based distributions.
+For the most part, the issues are due to RPM being able to have multiple
+packages of the same name installed.  This is an issue on all Red Hat
+and SUSE based distributions.
 
 Examples of this are:
 
@@ -28,10 +31,13 @@ the RPMng driver. Alternatively, you can use the newer :ref:`Packages
 Development Status
 ==================
 
-Initial development of the drivers was done on Centos 4.4 x86_64, with testing on openSUSE 10.2 x86_64. Centos has been tested with a new style Pkgmgr file and openSUSE with an old style file (see the Configuration section below for what this means).  Testing has now moved to Centos 5 x86_64 adn old style files are no longer (as of 0.9.5) being tested.
-
-RPMng/YUMng are the default RPM drivers from bcfg2 0.9.5 and later.
+Initial development of the drivers was done on Centos 4.4 x86_64, with
+testing on openSUSE 10.2 x86_64. Centos has been tested with a new style
+Pkgmgr file and openSUSE with an old style file (see the Configuration
+section below for what this means).  Testing has now moved to Centos 5
+x86_64 and old style files are no longer being tested.
 
+RPMng/YUMng are the default RPM drivers.
 
 Features
 ========
@@ -60,19 +66,30 @@ The rpmtools module conatins most of the rpm-python code and is imported by RPMn
 RPMng.RefreshPackages()
 -----------------------
 
-The RPMng.RefreshPackages method generates the installed dict using rpm-python code from the rpmtools module.  Full name, epoch, version, release and arch information is stored.
+The RPMng.RefreshPackages method generates the installed dict using
+rpm-python code from the rpmtools module. Full name, epoch, version,
+release and arch information is stored.
 
 RPMng.VerifyPackages()
 ----------------------
 
-The RPMng.VerifyPackages method generates a number of structures that record the state of the of the system compared to the bcfg2 literal configuration retrieved from the server.  These structures are mainly used by the RPMng.Install method.
+The RPMng.VerifyPackages method generates a number of structures that
+record the state of the of the system compared to the bcfg2 literal
+configuration retrieved from the server. These structures are mainly
+used by the RPMng.Install method.
 
-AS part of the verification process an rpm package level verification is carried out using rpm-python code from the rpmtools module.  Full details of the failures are returned in a complicated dict/list structure for later use.
+AS part of the verification process an rpm package level verification is
+carried out using rpm-python code from the rpmtools module.  Full details
+of the failures are returned in a complicated dict/list structure for
+later use.
 
 RPMng.Install()
 ---------------
 
-The RPMng.Install method attempts to fix what the  RPMng.VerifyPackages method found wrong.  It does this by installing, reinstalling, deleting and upgrading RPMs.   RPMng.Install does not use rpm-python.  It does use the following rppm commands as appropriate::
+The RPMng.Install method attempts to fix what the RPMng.VerifyPackages
+method found wrong. It does this by installing, reinstalling, deleting
+and upgrading RPMs. RPMng.Install does not use rpm-python. It does use
+the following rppm commands as appropriate::
 
     rpm -install
 
@@ -80,12 +97,19 @@ The RPMng.Install method attempts to fix what the  RPMng.VerifyPackages method f
 
     rpm -upgrade
 
-A method (RPMng.to reinstall_check()) to decide whether to do a reinstall of a package instance or not has been added, but is very simple at this stage.  Currently it will prevent a reinstall if the only reason for a verification failure was due to an RPM configuration (%config) file.  A package reinstall will not replace these, so there is no point reinstalling.
+A method (RPMng.to reinstall_check()) to decide whether to do a reinstall
+of a package instance or not has been added, but is very simple at
+this stage. Currently it will prevent a reinstall if the only reason
+for a verification failure was due to an RPM configuration (%config)
+file. A package reinstall will not replace these, so there is no point
+reinstalling.
 
 RPMng.Remove()
 --------------
 
-The RPMng.Remove method is written using rpm-python code in the rpmtools module.  Full nevra information is used in the selection of the package removal.
+The RPMng.Remove method is written using rpm-python code in the rpmtools
+module. Full nevra information is used in the selection of the package
+removal.
 
 Installation
 ============
@@ -93,7 +117,11 @@ Installation
 isprelink
 ---------
 
-This is a Python C extension module that checks to see if a file has been prelinked or not.  It should be built and installed on systems that have the prelink package installed (only Red Hat family systems as far as I can tell).  rpmtools will function without the isprelink module, but performance is not good.
+This is a Python C extension module that checks to see if a file has
+been prelinked or not. It should be built and installed on systems that
+have the prelink package installed (only Red Hat family systems as far
+as I can tell). rpmtools will function without the isprelink module,
+but performance is not good.
 
 Source can be found here ftp://ftp.mcs.anl.gov/pub/bcfg/isprelink-0.1.2.tar.gz
 
@@ -101,7 +129,8 @@ To compile and install prelink, execute::
 
     python setup.py install
 
-in the rpmtools directory. The elfutils-libelf-devel package is required for the compilation.
+in the rpmtools directory. The elfutils-libelf-devel package is required
+for the compilation.
 
 There are Centos x86_64 RPMs here ftp://ftp.mcs.anl.gov/pub/bcfg/redhat/
 
@@ -111,13 +140,15 @@ Configuration and Usage
 Loading of RPMng
 ----------------
 
-The RPMng driver can be loaded by command line options, client configuration file options or as the default driver for RPM packages.
+The RPMng driver can be loaded by command line options, client
+configuration file options or as the default driver for RPM packages.
 
 From the command line::
 
     bcfg2 -n -v -d -D Action,POSIX,Chkconfig,RPMng 
 
-This produces quite a bit of output so you may want to redirect the output to a file for review.
+This produces quite a bit of output so you may want to redirect the
+output to a file for review.
 
 In the bcfg2.conf file::
 
@@ -130,7 +161,9 @@ In the bcfg2.conf file::
 Configuration File Options
 --------------------------
 
-A number of paramters can be set in the client configuration for both the RPMng and YUMng drivers.  Each driver has its own section.  A full client configuration file with all the options specified is below::
+A number of paramters can be set in the client configuration for both
+the RPMng and YUMng drivers. Each driver has its own section. A full
+client configuration file with all the options specified is below::
 
     [communication]
     protocol = xmlrpc/ssl
@@ -166,13 +199,24 @@ A number of paramters can be set in the client configuration for both the RPMng
 installOnlyPkgs
 ^^^^^^^^^^^^^^^
 
-Install only packages are packages that should only ever be installed or deleted, not  upgraded.
+Install only packages are packages that should only ever be installed
+or deleted, not upgraded.
 
-The only packages for which this is an absolute on, are the gpg-pubkey packages.  It is however 'best' practice to only ever install/delete kernel packages.  The wisdom being that the package for the currently running kernel should always be installed.  Doing an upgrade would delete the running kernel package.
+The only packages for which this is an absolute on, are the gpg-pubkey
+packages. It is however 'best' practice to only ever install/delete
+kernel packages. The wisdom being that the package for the currently
+running kernel should always be installed. Doing an upgrade would delete
+the running kernel package.
 
-The RPMng driver follows the YUM practice of having a list of install only packages.  A default list is hard coded in RPMng.py.  This maybe over ridden in the client configuration file.
+The RPMng driver follows the YUM practice of having a list of install
+only packages. A default list is hard coded in RPMng.py. This maybe over
+ridden in the client configuration file.
 
-Note that except for gpg-pubkey packages (which are always added to the list by the driver) the list in the client configuration file completely replaces the default list.  An empty list means that there are no install only packages (except for gpg-pubkey), which is the behaviour of the old RPM driver.
+Note that except for gpg-pubkey packages (which are always added to the
+list by the driver) the list in the client configuration file completely
+replaces the default list. An empty list means that there are no install
+only packages (except for gpg-pubkey), which is the behaviour of the
+old RPM driver.
 
 Example - an empty list::
 
@@ -187,14 +231,18 @@ Example - The default list::
 erase_flags
 ^^^^^^^^^^^
 
-erase_flags are rpm options used by 'rpm -erase' in the client Remove() method.  The RPMng erase is written using rpm-python and does not use the rpm command.
+erase_flags are rpm options used by 'rpm -erase' in the client Remove()
+method. The RPMng erase is written using rpm-python and does not use
+the rpm command.
 
-The erase flags are specified in the client configuration file as a comma separated list and apply to all RPM erase operations.  The default is::
+The erase flags are specified in the client configuration file as a comma
+separated list and apply to all RPM erase operations. The default is::
 
     [RPMng]
     erase_flags = allmatches
 
-The following rpm erase options are supported, see the rpm man page for details.::
+The following rpm erase options are supported, see the rpm man page
+for details.::
 
     noscripts
     notriggers
@@ -209,9 +257,9 @@ pkg_checks
 
 The RPMng/YUMng drivers do the following three checks/status:
 
-# Installed
-# Version
-# rpm verify
+#. Installed
+#. Version
+#. rpm verify
 
 Setting pkg_checks = true (the default) in the client configuration file means that all three checks will be done for all packages.
 Setting pkg_checks = false in the client configuration file means that only the Installed check will be done for all packages.
@@ -227,9 +275,9 @@ pkg_verify
 
 The RPMng/YUMng drivers do the following three checks/status:
 
-# Installed
-# Version
-# rpm verify
+#. Installed
+#. Version
+#. rpm verify
 
 Setting pkg_verify = true (the default) in the client configuration file means that all three checks will be done for all packages as long as pkg_checks = true.
 Setting pkg_verify = false in the client configuration file means that the rpm verify wil not be done for all packages on the client. 
@@ -282,7 +330,9 @@ The RPMng/YUMng drivers do the following three checks/status:
 #. Version
 #. rpm verify
 
-verify_fail_action controls whether or not a package instance will be reinstlled if the version check fails (i.e. if the installed package instance isn't the same version as specified in the configuration).
+verify_fail_action controls whether or not a package instance will be
+reinstlled if the version check fails (i.e. if the installed package
+instance isn't the same version as specified in the configuration).
 
 If verify_fail_action = reinstall then the package instance is reinstalled.
 If verify_fail_action = none then the package instance is not reinstalled.
@@ -296,7 +346,10 @@ If verify_fail_action = none then the package instance is not reinstalled.
 Interactive Mode
 ----------------
 
-Running the client in interactive mode (-I) prompts for the actions to be taken as before.  Prompts are per package and may apply to multiple instances of that package.  Each per package prompt will contain a list of actions per instance.
+Running the client in interactive mode (-I) prompts for the actions to
+be taken as before.  Prompts are per package and may apply to multiple
+instances of that package.  Each per package prompt will contain a list
+of actions per instance.
 
 Actions are encoded as 
 
@@ -309,7 +362,6 @@ R - Reinstall
 U - Upgrade/Downgrade
 
 
-
 An example is below.  The example is from a system that is still using the old Pkgmgr format, so the epoch and arch appear as '*'.::
 
     Install/Upgrade/delete Package aaa_base instance(s) - R(*:10.2-38.*)  (y/N)
@@ -326,21 +378,41 @@ An example is below.  The example is from a system that is still using the old P
 GPG Keys
 --------
 
-GPG is used by RPM to 'sign' packages.  All vendor packages are signed with the vendors GPG key.  Additional signatures maybe added to the rpm file at the users discretion.
+GPG is used by RPM to 'sign' packages. All vendor packages are signed
+with the vendors GPG key. Additional signatures maybe added to the rpm
+file at the users discretion.
 
-It is normal to have multiple GPG keys installed.  For example, SLES10 out of the box has six GPG keys installed.
+It is normal to have multiple GPG keys installed. For example, SLES10
+out of the box has six GPG keys installed.
 
-To the RPM database all GPG 'packages' have the name 'gpg-pubkey', which may be nothing like the name of the file specified in the rpm -import command.  For example on Centos 4 the file name is RPM-GPG-KEY-centos4.  For SLES10 this means that there are six packages with the name 'gpg-pubkey' installed.
+To the RPM database all GPG 'packages' have the name 'gpg-pubkey', which
+may be nothing like the name of the file specified in the rpm -import
+command. For example on Centos 4 the file name is RPM-GPG-KEY-centos4.
+For SLES10 this means that there are six packages with the name
+'gpg-pubkey' installed.
 
 RPM does not check GPG keys at package installation, YUM does.
 
-RPMng uses the rpm command for installation and does not therefore check GPG signatures at package install time.  RPMng uses rpm-python for verification and does by default do signature checks as part of the client Inventory process.  To do the signature check the appropriate GPG keys must be installed.  rpm-python is not very friendly if the required key(s) is not installed (it crashes the client).
+RPMng uses the rpm command for installation and does not therefore
+check GPG signatures at package install time. RPMng uses rpm-python
+for verification and does by default do signature checks as part of the
+client Inventory process. To do the signature check the appropriate GPG
+keys must be installed. rpm-python is not very friendly if the required
+key(s) is not installed (it crashes the client).
 
-The RPMng driver detects, on a per package instance basis, if the appropriate key is installed.  If it is not, a warning message is printed and the signature check is disabled for that package instance, for that client run only.
+The RPMng driver detects, on a per package instance basis, if the
+appropriate key is installed. If it is not, a warning message is printed
+and the signature check is disabled for that package instance, for that
+client run only.
 
-GPG keys can be installed and removed by the RPMng driver.  To install a GPG key configure it in Pkgmgr/Rules as a package and add gpg-pubkey to the clients abstract configuration.  The gpg-pubkey package/instance is treated as an install only package.  gpg-pubkey packages are installed by the RPMng driver with the rpm -import command.  
+GPG keys can be installed and removed by the RPMng driver. To install a
+GPG key configure it in Pkgmgr/Rules as a package and add gpg-pubkey to
+the clients abstract configuration. The gpg-pubkey package/instance is
+treated as an install only package. gpg-pubkey packages are installed
+by the RPMng driver with the rpm -import command.
 
-gpg-pubkey packages will be removed by bcfg2 -r packages if they are not in the clients configuration.
+gpg-pubkey packages will be removed by bcfg2 -r packages if they are
+not in the clients configuration.
 
 .. code-block:: xml
 
@@ -360,51 +432,94 @@ Example gpg-pubkey Pkgmgr configuration file.
 Pkgmgr Configuration
 --------------------
 
-Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages.
+Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>`
+and :ref:`unsorted-altsrc` pages.
  
 Package Tag (Old style)
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-Old style (meaning no Instance tag) Pkgmgr files have limited support.  Specifically the multiarch and verify attributes are ignored. 
+Old style (meaning no Instance tag) Pkgmgr files have limited support.
+Specifically the multiarch and verify attributes are ignored.
 
 If multiarch type support is needed a new style format file must be used.
 
-If some control over the verification is needed, replace the verify attribute with the pkg_checks or verify_flags attributes.  The pkg_checks and verify_flags attributes are detailed under the Instance tag heading.
+If some control over the verification is needed, replace the verify
+attribute with the pkg_checks or verify_flags attributes. The pkg_checks
+and verify_flags attributes are detailed under the Instance tag heading.
 
 Package Tag (New Style) and Attributes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The new style package tag supports the name and pkg_checks attributes and requires the use of Instance tag entries.
+The new style package tag supports the name and pkg_checks attributes
+and requires the use of Instance tag entries.
 
-New style configuration files must be generated from the RPM headers.  Either from RPM files or from the RPM DB.  
+New style configuration files must be generated from the RPM headers.
+Either from RPM files or from the RPM DB.
 
-The included pkgmgr_gen.py can be used as a starting point for generating configuration files from directories of RPM package files.  pkgmgr_gen.py --help for the options.
+The included pkgmgr_gen.py can be used as a starting point for generating
+configuration files from directories of RPM package files. pkgmgr_gen.py
+--help for the options.
 
-The included pkgmgr_update.py can be used to update the package instance versions in configuration files from directories of package files.  pkgmgr_update.py --help for the options.
+The included pkgmgr_update.py can be used to update the package instance
+versions in configuration files from directories of package files.
+pkgmgr_update.py --help for the options.
 
-|| '' '''Attribute''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name || Package name. || String ||
-|| pkg_checks || Do the version and rpm verify checks.  || true(default) or false ||
++------------+---------------------------------------+------------------------+
+| Attribute  | Description                           | Values                 |
++============+=======================================+========================+
+| name       | Package name.                         | String                 |
++------------+---------------------------------------+------------------------+
+| pkg_checks | Do the version and rpm verify checks. | true(default) or false |
++------------+---------------------------------------+------------------------+
 
 Instance Tag and Attributes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The instance tag supports the following attributes:
 
-|| '' '''Attribute''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| simplefile || Package file name. || String (see Notes below) ||
-|| epoch || Package epoch. || String (numeric only) (optional) ||
-|| version || Package version. || String ||
-|| release || Package release. || String ||
-|| arch || Package architecture. || Architecture String e.g. (i386|i586|i686|x86_64) ||
-|| verify_flags || Comma separated list of rpm --verify options.  See the rpm man page for their details. || nodeps, nodigest, nofiles, noscripts, nosignature, nolinkto, nomd5, nosize, nouser, nogroup, nomtime, nomode, nordev ||
-|| pkg_verify || Do the rpm verify || true(default) or false||
-|| install_action || Install package instance if it is not installed. || install(default) or none ||
-|| version_fail_action || Upgrade package if the incorrect version is installed. || upgrade(default) or none ||
-|| verify_fail_action || Reinstall the package instance if the rpm verify failed. || reinstall(default) or none ||
++---------------------+----------------------------+--------------------------+
+| Attribute           | Description                | Values                   |
++=====================+============================+==========================+
+| simplefile          | Package file name.         | String (see Notes below) |
++---------------------+----------------------------+--------------------------+
+| epoch               | Package epoch.             | String (numeric only)    |
+|                     |                            | (optional)               |
++---------------------+----------------------------+--------------------------+
+| version             | Package version.           | String                   |
++---------------------+----------------------------+--------------------------+
+| release             | Package release.           | String                   |
++---------------------+----------------------------+--------------------------+
+| arch                | Package architecture.      | Architecture String e.g. |
+|                     |                            | (i386|i586|i686|x86_64)  |
++---------------------+----------------------------+--------------------------+
+| verify_flags        | Comma separated list of    | nodeps, nodigest,        |
+|                     | rpm --verify options. See  | nofiles, noscripts,      |
+|                     | the rpm man page for their | nosignature, nolinkto,   |
+|                     | details.                   | nomd5, nosize, nouser,   |
+|                     |                            | nogroup, nomtime,        |
+|                     |                            | nomode, nordev           |
++---------------------+----------------------------+--------------------------+
+| pkg_verify          | Do the rpm verify          | true(default) or false   |
++---------------------+----------------------------+--------------------------+
+| install_action      | Install package instance   | install(default) or none |
+|                     | if it is not installed.    |                          |
++---------------------+----------------------------+--------------------------+
+| version_fail_action | Upgrade package if the     | upgrade(default) or none |
+|                     | incorrect version is       |                          |
+|                     | installed.                 |                          |
++---------------------+----------------------------+--------------------------+
+| verify_fail_action  | Reinstall the package      | reinstall(default) or    |
+|                     | instance if the rpm verify | none                     |
+|                     | failed                     |                          |
++---------------------+----------------------------+--------------------------+
 
 .. note::
-    The simplefile attribute doesn't need to be just the filename, meaning the basename.  It is joined with the uri attribute from the PackageList Tag to form the URL that the client will use to download the package.  So the uri could just be the host portion of the url and simple file could be the directory path.
+
+    The simplefile attribute doesn't need to be just the filename,
+    meaning the basename.  It is joined with the uri attribute from the
+    PackageList Tag to form the URL that the client will use to download
+    the package.  So the uri could just be the host portion of the url
+    and simple file could be the directory path.
 
     e.g.
 
@@ -421,29 +536,41 @@ The instance tag supports the following attributes:
             </Group>
         </PackageList>
 
-The values for epoch, version, release and arch attributes must come from the RPM header, not the RPM file name.
+The values for epoch, version, release and arch attributes must come
+from the RPM header, not the RPM file name.
 
 Epoch is a strange thing. In short::
 
     epoch not set == epoch=None < epoch='0' < epoch='1'
 
-and it is an int, but elementtree attributes have to be str or unicode, so the driver is constantly converting.
+and it is an int, but elementtree attributes have to be str or unicode,
+so the driver is constantly converting.
 
 Ignore Tag
 ^^^^^^^^^^
 
-The Ignore tag is used to "mask out" individual files from the RPM verification.  This is done by comparing the verification failure results with the Ignore tag name.  If there is a match, that entry is not used by the client to determine if a package has failed verification.
+The Ignore tag is used to "mask out" individual files from the RPM
+verification.  This is done by comparing the verification failure results
+with the Ignore tag name.  If there is a match, that entry is not used
+by the client to determine if a package has failed verification.
 
-Ignore tag entries can be specified at both the Package level, in which case they apply to all Instances, and/or at the Instance level, in which case they only apply to that instance.
+Ignore tag entries can be specified at both the Package level, in which
+case they apply to all Instances, and/or at the Instance level, in which
+case they only apply to that instance.
 
-Ignore tag entries only work with the RPMng driver. They do not appear to be supported in YUMng as of 1.0pre5.
+Ignore tag entries only work with the RPMng driver. They do not appear
+to be supported in YUMng as of 1.0pre5.
 
-Ignore tag entries can be specified in both old and new style Pkgmgr files.
+Ignore tag entries can be specified in both old and new style Pkgmgr
+files.
 
 The Ignore Tag supports the following attributes:
 
-|| '' '''Attribute''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name || File name. || String ||
++-----------+-------------+--------+
+| Attribute | Description | Values |
++===========+=============+========+
+| name      | File name.  | String |
++-----------+-------------+--------+
 
 Example
 
@@ -457,17 +584,20 @@ Example
 Automated Generation of Pkgmgr Configuration Files
 --------------------------------------------------
 
-The two utilities detailed below are provided in the tools directory of the source tarball.
+The two utilities detailed below are provided in the tools directory of
+the source tarball.
 
-Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages.
+Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>`
+and :ref:`unsorted-altsrc` pages.
 
 pkgmgr_gen.py
 ^^^^^^^^^^^^^
 
-pkgmgr_gen will generate a Pkgrmgr file from a list of directories containing RPMs or from a list of YUM repositories.::
- 
-    [root@bcfg2 Pkgmgr]# pkgmgr_gen.py --help
-    usage: pkgmgr_gen.py [options]
+pkgmgr_gen will generate a Pkgmgr file from a list of directories
+containing RPMs or from a list of YUM repositories.::
+
+    [root@bcfg2 Pkgmgr]# pkgmgr_gen.py --help usage: pkgmgr_gen.py
+    [options]
 
     options:
       -h, --help            show this help message and exit
@@ -517,7 +647,10 @@ pkgmgr_gen will generate a Pkgrmgr file from a list of directories containing RP
 pkgmgr_update.py
 ----------------
 
-pkgmgr_update will update the release (meaning the epoch, version and release) information in an existing Pkgrmgr file from a list of directories containing RPMs or from a list of YUM repositories.  All Tags and other attributes in the existing file will remain unchanged.::
+pkgmgr_update will update the release (meaning the epoch, version
+and release) information in an existing Pkgrmgr file from a list of
+directories containing RPMs or from a list of YUM repositories.  All Tags
+and other attributes in the existing file will remain unchanged.::
 
     [root@bcfg2 Pkgmgr]# pkgmgr_update.py --help
     usage: pkgmgr_update.py [options]
@@ -542,7 +675,8 @@ Pkgmgr Configuration Examples
 verify_flags
 ^^^^^^^^^^^^
 
-This entry was used for the Centos test client used during RPMng development.
+This entry was used for the Centos test client used during RPMng
+development.
 
 .. code-block:: xml
 
@@ -577,7 +711,8 @@ Per Instance Ignore
 
 .. note:: In this case a per instance ignore is actually a bad idea as the verify failure is because of multiarch issues where  the last package installed wins.  So this would be better as a Package level ignore.
 
-Ignore tag entries only work with the RPMng driver.  They do not appear to be supported in YUMng as of 1.0pre5.
+Ignore tag entries only work with the RPMng driver. They do not appear
+to be supported in YUMng as of 1.0pre5.
 
 .. code-block:: xml
 
@@ -591,7 +726,8 @@ Ignore tag entries only work with the RPMng driver.  They do not appear to be su
 pkg_checks
 ^^^^^^^^^^
 
-If pkg_checks = false the version information is not required.  If pkg_checks = true the full information is needed as normal.
+If pkg_checks = false the version information is not required. If
+pkg_checks = true the full information is needed as normal.
 
 For YUMng a minimal entry is
 
@@ -599,7 +735,9 @@ For YUMng a minimal entry is
 
     <Package name="bcfg2" type="yum" pkg_checks="False"/>
 
-Infact for YUMng, with pkg_checks = false, any combination of the nevra attributes that will build a valid yum package name (see the Misc heading on the yum man page) is valid.
+In fact for YUMng, with pkg_checks = false, any combination of the nevra
+attributes that will build a valid yum package name (see the Misc heading
+on the yum man page) is valid.
 
 .. code-block:: xml
 
@@ -614,7 +752,8 @@ For RPMng a minimal entry is
 verify_fail_action
 ^^^^^^^^^^^^^^^^^^
 
-The way I have bcfg2 configured for my development systems.  This way it reports bad, but doesn't do anything about it.
+The way I have bcfg2 configured for my development systems. This way
+it reports bad, but doesn't do anything about it.
 
 .. code-block:: xml
 
diff --git a/doc/faq/general.txt b/doc/faq/general.txt
index b846e58eb..af54e9002 100644
--- a/doc/faq/general.txt
+++ b/doc/faq/general.txt
@@ -6,13 +6,23 @@ FAQ: General
 What does Bcfg2 stand for?
 --------------------------
 
-Initially, Bcfg stood for the bundle configuration system. Bcfg2 is the second major revision. At this point, the acronym is meaningless, but the name has stuck. Luckily, Bcfg2 googles better than Bcfg does. No, seriously. Try it. All I know is that I have no interest in a billion cubic feet of gas.
+Initially, Bcfg stood for the bundle configuration system. Bcfg2 is the
+second major revision. At this point, the acronym is meaningless, but
+the name has stuck. Luckily, Bcfg2 googles better than Bcfg does. No,
+seriously. Try it. All I know is that I have no interest in a billion
+cubic feet of gas.
 
 What architectures does Bcfg2 support?
 --------------------------------------
 
-Bcfg2 should run on any POSIX compatible operating system, however direct support for an operating system's package and service formats are limited by the currently available :ref:`client-tools-index` (although new client tools are pretty easy to add). The following is an incomplete but more exact list of platforms on which Bcfg2 works.
+Bcfg2 should run on any POSIX compatible operating system, however direct
+support for an operating system's package and service formats are limited
+by the currently available :ref:`client-tools-index` (although new client
+tools are pretty easy to add). The following is an incomplete but more
+exact list of platforms on which Bcfg2 works.
 
 * GNU/Linux deb based distros
 * GNU/Linux rpm based distros
 * Solaris pkg based
+* Gentoo portage based
+* OSX (POSIX/launchd support)
diff --git a/doc/obsolete/index.txt b/doc/obsolete/index.txt
index 28fcf2b0c..87f97ac5a 100644
--- a/doc/obsolete/index.txt
+++ b/doc/obsolete/index.txt
@@ -5,7 +5,9 @@
 Deprecated/obsolete documentation
 =================================
 
-These documents cover features that have been deprecated or that have been replaced in newer versions of Bcfg2. They're preserved here for folks using old versions of Bcfg2.
+These documents cover features that have been deprecated or that have
+been replaced in newer versions of Bcfg2. They're preserved here for
+folks using old versions of Bcfg2.
 
 .. toctree::
    :maxdepth: 1
diff --git a/doc/quickstart/ubuntu.txt b/doc/quickstart/ubuntu.txt
index b4a0b38fe..2761187c6 100644
--- a/doc/quickstart/ubuntu.txt
+++ b/doc/quickstart/ubuntu.txt
@@ -13,7 +13,9 @@ This is a complete getting started guide for Ubuntu
 Install Bcfg2
 -------------
 
-We first need to install the server. For this example, we will use the bcfg2 server package from the bcfg2 `PPA`_ (note that there is also a version available in the ubuntu archives, but it is not as up to date).
+We first need to install the server. For this example, we will use the
+bcfg2 server package from the bcfg2 `PPA`_ (note that there is also a
+version available in the ubuntu archives, but it is not as up to date).
 
 .. _PPA: https://launchpad.net/~bcfg2/+archive/ppa
 
@@ -35,7 +37,9 @@ Remove the default configuration preseeded by the ubuntu package::
 Initialize your repository
 --------------------------
 
-Now that you're done with the install, you need to intialize your repository and setup your bcfg2.conf. bcfg2-admin init is a tool which allows you to automate this process. ::
+Now that you're done with the install, you need to intialize your
+repository and setup your bcfg2.conf. bcfg2-admin init is a tool which
+allows you to automate this process.::
 
     root@lucid:~# bcfg2-admin init
     Store bcfg2 configuration in [/etc/bcfg2.conf]: 
@@ -68,7 +72,7 @@ Of course, change responses as necessary.
 Start the server
 ----------------
 
-You are now ready to start your bcfg2 server for the first time. ::
+You are now ready to start your bcfg2 server for the first time.::
 
     root@lucid:~# /etc/init.d/bcfg2-server start
     root@lucid:~# tail /var/log/syslog
@@ -76,7 +80,7 @@ You are now ready to start your bcfg2 server for the first time. ::
     Dec 17 22:07:02 lucid bcfg2-server[17523]: serve_forever() [start]
     Dec 17 22:07:02 lucid bcfg2-server[17523]: Processed 16 fam events in 0.502 seconds. 0 coalesced
 
-Run bcfg2 to be sure you are able to communicate with the server ::
+Run bcfg2 to be sure you are able to communicate with the server::
 
     root@lucid:~# bcfg2 -vqn
     Loaded tool drivers:
@@ -98,7 +102,8 @@ Run bcfg2 to be sure you are able to communicate with the server ::
 Bring your first machine under Bcfg2 control
 --------------------------------------------
 
-Now it is time to get your first machine's configuration into your Bcfg2 repository. Let's start with the server itself.
+Now it is time to get your first machine's configuration into your Bcfg2
+repository. Let's start with the server itself.
 
 Setup the `Packages`_ plugin
 +++++++++++++++++++++++++++++++++++++++++++++++++
@@ -139,7 +144,8 @@ Replace Pkgmgr with Packages in the plugins line of bcfg2.conf::
     [components]
     bcfg2 = https://lucid:6789
 
-Create Packages layout (as per [wiki:Plugins/Packages#Exampleusage]) in /var/lib/bcfg2
+Create Packages layout (as per [wiki:Plugins/Packages#Exampleusage])
+in ``/var/lib/bcfg2``
 
 .. code-block:: xml
 
@@ -159,7 +165,10 @@ Create Packages layout (as per [wiki:Plugins/Packages#Exampleusage]) in /var/lib
       </APTSource>
     </Sources>
 
-Due to the `Magic Groups`_, we need to modify our Metadata. Let's add an **ubuntu-lucid** group which inherits the **ubuntu** group already present in /var/lib/bcfg2/Metadata/groups.xml. The resulting file should look something like this
+Due to the `Magic Groups`_, we need to modify our Metadata. Let's add
+an **ubuntu-lucid** group which inherits the **ubuntu** group already
+present in /var/lib/bcfg2/Metadata/groups.xml. The resulting file should
+look something like this
 
 .. _Magic Groups: http://trac.mcs.anl.gov/projects/bcfg2/wiki/Plugins/Packages#MagicGroups
 
@@ -185,7 +194,10 @@ Due to the `Magic Groups`_, we need to modify our Metadata. Let's add an **ubunt
 .. note::
     When editing your xml files by hand, it is useful to occasionally run `bcfg2-repo-validate` to ensure that your xml validates properly.
 
-The last thing we need is for the client to have the proper arch group membership. For this, we will make use of the [wiki:DynamicGroups] capabilities of the Probes plugin. Add Probes to your plugins line in bcfg2.conf and create the Probe.
+The last thing we need is for the client to have the proper arch group
+membership. For this, we will make use of the [wiki:DynamicGroups]
+capabilities of the Probes plugin. Add Probes to your plugins line in
+bcfg2.conf and create the Probe.
 
 .. code-block:: sh
 
@@ -227,7 +239,8 @@ Now we restart the bcfg2-server::
 Start managing packages
 +++++++++++++++++++++++
 
-Add a base-packages bundle. Let's see what happens when we just populate it with the ubuntu-standard package.
+Add a base-packages bundle. Let's see what happens when we just populate
+it with the ubuntu-standard package.
 
 .. code-block:: xml
 
@@ -236,7 +249,8 @@ Add a base-packages bundle. Let's see what happens when we just populate it with
             <Package name='ubuntu-standard'/>
     </Bundle>
 
-You need to reference the bundle from your Metadata. The resulting profile group might look something like this
+You need to reference the bundle from your Metadata. The resulting
+profile group might look something like this
 
 .. code-block:: xml
 
@@ -245,7 +259,8 @@ You need to reference the bundle from your Metadata. The resulting profile group
        <Group name='ubuntu-lucid'/>
     </Group>
 
-Now if we run the client in debug mode (-d), we can see what this has done for us. ::
+Now if we run the client in debug mode (-d), we can see what this has
+done for us.::
 
     root@lucid:~# bcfg2 -vqdn
     Running probe groups
@@ -282,7 +297,11 @@ Now if we run the client in debug mode (-d), we can see what this has done for u
     Total managed entries:  101
     Unmanaged entries:      281
 
-As you can see, the Packages plugin has generated the dependencies required for the ubuntu-standard package for us automatically. The ultimate goal should be to move all the packages from the **Unmanaged** entries section to the **Managed** entries section. So, what exactly *are* those Unmanaged entries? ::
+As you can see, the Packages plugin has generated the dependencies
+required for the ubuntu-standard package for us automatically. The
+ultimate goal should be to move all the packages from the **Unmanaged**
+entries section to the **Managed** entries section. So, what exactly *are*
+those Unmanaged entries?::
 
     root@lucid:~# bcfg2 -vqen
     Running probe groups
@@ -308,7 +327,11 @@ As you can see, the Packages plugin has generated the dependencies required for
      Package:apport
      ...
 
-Now you can go through these and continue adding the packages you want to your Bundle. Note that `aptitude why` is useful when trying to figure out the reason for a package being installed. Also, deborphan is helpful for removing leftover dependencies which are no longer needed. After a while, I ended up with a minimal bundle that looks like this
+Now you can go through these and continue adding the packages you want to
+your Bundle. Note that ``aptitude why`` is useful when trying to figure
+out the reason for a package being installed. Also, deborphan is helpful
+for removing leftover dependencies which are no longer needed. After a
+while, I ended up with a minimal bundle that looks like this
 
 .. code-block:: xml
 
@@ -383,7 +406,8 @@ As you can see below, I no longer have any unmanaged packages. ::
 Manage services
 +++++++++++++++
 
-Now let's clear up the unmanaged service entries by adding the following entries to our bundle...
+Now let's clear up the unmanaged service entries by adding the following
+entries to our bundle...
 
 .. code-block:: xml
 
@@ -448,6 +472,7 @@ Dynamic (web) Reports
 ---------------------
 
 First, `aptitude install python-django apache2 libapache2-mod-python`.
+
  * Now we need to create the sqlite database::
 
     root@lucid:~# python /usr/share/pyshared/Bcfg2/Server/Reports/manage.py syncdb
diff --git a/doc/server/plugins/generators/tgenshi/index.txt b/doc/server/plugins/generators/tgenshi/index.txt
index f482fa143..186652029 100644
--- a/doc/server/plugins/generators/tgenshi/index.txt
+++ b/doc/server/plugins/generators/tgenshi/index.txt
@@ -85,6 +85,49 @@ Produces:
 This flexibility provides the ability to build much more compact and
 succinct definitions of configuration contents than Cfg can.
 
+Templating Access Data
+======================
+
+These examples depend on the :ref:`server-plugins-grouping-BB` plugin. The
+BB plugin provides additional data about users that have been allocated
+nodes. It maps in a dictionary of user priviledges to client metadata
+instances.  Each of these plugins use this data. On this system, node
+allocations map to sudo and root access.
+
+``/var/lib/bcfg2/TGenshi/etc/sudoers/template.newtxt``::
+
+    # /etc/sudoers
+    #
+    # This file MUST be edited with the 'visudo' command as root.
+    #
+    # See the man page for details on how to write a sudoers file.
+    # Host alias specification
+
+    # User alias specification
+    User_Alias ADMIN =
+    ${','.join(metadata.BB['users'].keys())},admin1,admin2
+    User_Alias IMAGERS = user1,user2,user3
+
+    # Cmnd alias specification
+    Cmnd_Alias      SYSTEMIMAGER = /usr/sbin/getimage [A-z]* [A-z]*
+
+    # Defaults
+
+    Defaults        !lecture,tty_tickets,!fqdn
+
+    # User privilege specification
+    root    ALL=(ALL) ALL
+    IMAGERS login=SYSTEMIMAGER
+
+    # Members of the admin group may gain root privileges
+    ADMIN ALL=(ALL) ALL
+
+``/var/lib/bcfg2/TGenshi/root/.ssh/authorized_keys/template.newtxt``::
+
+    {% for user in metadata.BB['users'] %}
+    ${"\n".join(metadata.BB['users'][user])}
+    {% end %}
+
 FAQs
 ====
 
diff --git a/doc/server/plugins/structures/bundler/index.txt b/doc/server/plugins/structures/bundler/index.txt
index d4a2cc2d1..fc6e7244a 100644
--- a/doc/server/plugins/structures/bundler/index.txt
+++ b/doc/server/plugins/structures/bundler/index.txt
@@ -155,7 +155,7 @@ in their name. The following template produces such a config file entry.
 Depending on the circumstance, these configuration files can either be
 handled by individual entries in :ref:`server-plugins-generators-cfg`,
 :ref:`server-plugins-generators-tcheetah`, or
-:ref:`server-plugins-generators-tgenshi`, or can be mapped to a single
+:ref:`server-plugins-generators-tgenshi-index`, or can be mapped to a single
 entry by using the [wiki:altsrc] feature.
 
 In this example, configuration file names are built using probed results
diff --git a/doc/server/reports/dynamic.txt b/doc/server/reports/dynamic.txt
index a22132afb..a5c748481 100644
--- a/doc/server/reports/dynamic.txt
+++ b/doc/server/reports/dynamic.txt
@@ -12,9 +12,13 @@ Installation
 Overview
 --------
 
-Installation of the new reporting system requires installation of a python module and configuration of the Apache webserver with a virtual host. Additionally, until fully integrated, periodically an "import script" must be executed via Cron or similar mechanism.
+Installation of the new reporting system requires installation of a
+python module and configuration of the Apache webserver with a virtual
+host. Additionally, until fully integrated, periodically an "import
+script" must be executed via Cron or similar mechanism.
 
-Versions 0.9.5pre1 and greater no longer need to be installed at the root url for a given host, and therefore no longer require their own virtual host.
+Reports no longer needs to be installed at the root URL for a given
+host. Therefore, reports no longer require their own virtual host.
 
 Prerequisites
 -------------
@@ -29,20 +33,26 @@ Install
 
 '''setup bcfg2.conf or bcfg2-web.conf'''
 
-Be sure to include the specified fields included the example bcfg2.conf file. These can be specified in either /etc/bcfg2.conf, if it is readable by the webserver user, or /etc/bcfg2-web.conf.
-
+Be sure to include the specified fields included the example bcfg2.conf
+file. These can be specified in either ``/etc/bcfg2.conf``, if it is readable
+by the webserver user, or ``/etc/bcfg2-web.conf``.
 
 '''Install skeleton database'''
 
-Inside the {{{bcfg2-tarball/examples/}}} directory from the tarball you will find {{{brpt.sqlite}}}. Copy this file to <path-to-bcfg2-repository>/etc/brpt.sqlite
+Inside the ``bcfg2-tarball/examples/`` directory from the
+tarball you will find ``brpt.sqlite``. Copy this file to
+<path-to-bcfg2-repository>/etc/brpt.sqlite
 
-If you are not using sqlite (the default choice), please see the "Notes on Alternative Databases" section below.
+If you are not using sqlite (the default choice), please see the "Notes
+on Alternative Databases" section below.
 
-At this point we can import statistics date in to the database from your {{{clients.xml}}} and {{{statistics.xml}}} files.
+At this point we can import statistics date in to the database from your
+``clients.xml`` and ``statistics.xml`` files.
 
 execute the following: {{{python .../site-packages/Bcfg2/Server/Reports/importscript.py }}}
 
-At this point you shouldn't get any errors or tracebacks. Common problems include incorrect installation of the pysqlite2 module.
+At this point you shouldn't get any errors or tracebacks. Common problems
+include incorrect installation of the pysqlite2 module.
 
 '''Next we configure Apache:'''
 
@@ -98,7 +108,13 @@ on a regular basis, perhaps as often as every 5 or 10 minutes or as infrequent a
 Notes on Alternative Databases
 ------------------------------
 
- If you choose to use a different database, you'll need to edit settings.py from inside of the brpt module. Instructions on this process can be found on the Django website. The provided sqlite database file is pre-populated with the appropriate tables, if you choose a different database engine, you will need to run "python manage.py syncdb" from the brpt module directory to configure it before importing any data. As of vers 0.9.5, these settings are moved to the more appropriate /etc/bcfg2.conf
+If you choose to use a different database, you'll need to edit settings.py
+from inside of the brpt module. Instructions on this process can be found
+on the Django website. The provided sqlite database file is pre-populated
+with the appropriate tables, if you choose a different database engine,
+you will need to run "python manage.py syncdb" from the brpt module
+directory to configure it before importing any data. As of vers 0.9.5,
+these settings are moved to the more appropriate /etc/bcfg2.conf
 
 
 ''If you encounter any problems or have suggestions for these instructions feedback is welcome and encouraged.''
@@ -106,7 +122,11 @@ Notes on Alternative Databases
 Summary and Features
 ====================
 
-The new reporting system was implemented to address a number of deficiencies in the previous system. By storing statistics data in a relational database, we are now able to view and analyze more information about the state of the configuration, including information about previous configuration. Specific features in the new system include:
+The new reporting system was implemented to address a number of
+deficiencies in the previous system. By storing statistics data in a
+relational database, we are now able to view and analyze more information
+about the state of the configuration, including information about previous
+configuration. Specific features in the new system include:
 
 * The ability to look at past statistics information. [[Image(summary_cal.jpg, 30%, right)]]
 * More recent data concerning hosts. The import script may be run quite often, updating the database that contains all statistics information. In the future we anticipate development of a database based statistics module for the server that will allow statistics updates to happen immediately as configuration changes happen.
@@ -120,19 +140,34 @@ Planned improvements include
 * Config browsing capabilities; to look at your config in an interesting way.
 * Fixing all the known bugs from below. 
 
-Unfortunately with all the improvements, there are a few less exciting elements about the new reporting system. The new reporting system moves away from static pages and towards a real web application, which causes mainly problems with dependancies and makes installation and more difficult. This should become less of a problem over time as Django is packaged and we develop a better installation process for a web app. This should become clear when reading the Installation section that follows.
+Unfortunately with all the improvements, there are a few less exciting
+elements about the new reporting system. The new reporting system
+moves away from static pages and towards a real web application, which
+causes mainly problems with dependancies and makes installation and more
+difficult. This should become less of a problem over time as Django is
+packaged and we develop a better installation process for a web app. This
+should become clear when reading the Installation section that follows.
 
 Usage
 =====
 
-You can use these new reports in tandem with the old system. Currently the new reporting system simply periodically runs an importer script via cron. This imports the XML statistics and clients files to the relational database, building historical information. In the future, a new statistics module in the server will allow direct writing to the database whenever a configuration interaction occurs, which will make the reports always up to date.
+You can use these new reports in tandem with the old system. Currently
+the new reporting system simply periodically runs an importer script
+via cron. This imports the XML statistics and clients files to the
+relational database, building historical information. In the future,
+a new statistics module in the server will allow direct writing to the
+database whenever a configuration interaction occurs, which will make
+the reports always up to date.
 
 bcfg2-reports (command line script)
 -----------------------------------
 
-bcfg2-reports allows you to retrieve data from the database about clients, and the states of their current interactions. It also allows you to change the expired/unexpired states.
+bcfg2-reports allows you to retrieve data from the database about clients,
+and the states of their current interactions. It also allows you to
+change the expired/unexpired states.
 
-The utility runs as a standalone application. It does, however, use the models from /src/lib/Server/Reports/reports/models.py.
+The utility runs as a standalone application. It does, however, use the
+models from ``/src/lib/Server/Reports/reports/models.py``.
 
 A number of different options can be used to change what bcfg2-reports
 displays::
diff --git a/doc/unsorted/index.txt b/doc/unsorted/index.txt
index e9f7794ef..f2e5f52fd 100644
--- a/doc/unsorted/index.txt
+++ b/doc/unsorted/index.txt
@@ -14,20 +14,16 @@ list below.
 .. _TitleIndex: https://trac.mcs.anl.gov/projects/bcfg2/wiki/TitleIndex
 
 * `ManualPages`
-* `NewDynamicReports`
-* `NewDynamicReportsInstallation`
 * `Plugins/Actions`
 * `Plugins/Ohai`
 * `Plugins/Snapshots`
 * `PrecompiledPackages`
-* `Prereqs`
 * `Publications`
 * `QuickStart2`
 * `QuickStart3`
 * `SchemaEvolution`
 * `SecurityDevPlan`
 * `ServerSideOverview`
-* `TGenshi/examples/Templated_Access`
 * `TOC`
 * `Troubleshooting`
 * `UpgradeTesting`