doc: Fixes (links/tables) from Thorsten Lockert

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

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

7 files changed, 296 insertions, 109 deletions

diff --git a/doc/plugins/generators/hostbase.txt b/doc/plugins/generators/hostbase.txt
index 20cab349a..18bda9964 100644
--- a/doc/plugins/generators/hostbase.txt
+++ b/doc/plugins/generators/hostbase.txt
@@ -21,7 +21,7 @@ Prerequisites
 
  * mysql
  * python-mysqldb
- * [http://www.djangoproject.com Django] 0.95 or greater
+ * `Django <http://www.djangoproject.com>`_
 
 Install
 -------
@@ -42,11 +42,25 @@ Create the hostbase database and a user.  For MySQL users::
            BY 'password' WITH GRANT OPTION;
     mysql> quit
 
-As of Bcfg2 v0.8.7 configuration options for Hostbase have moved to {{{/etc/bcfg2.conf}}}.  There is an example bcfg2.conf with Hostbase options located at {{{bcfg2-tarball/examples/bcfg2.confHostbase}}}.  Edit the hostbase options to correspond to the database you've initialized and copy the configuration to {{{/etc/bcfg2.conf}}}.  To finish creating the database, from your {{{path to python/Bcfg2/Server/Hostbase}}} directory, run {{{python manage.py syncdb}}} to do all table creation.
+As of Bcfg2 v0.8.7 configuration options for Hostbase have moved to
+``/etc/bcfg2.conf``.  There is an example bcfg2.conf with Hostbase
+options located at ``bcfg2-tarball/examples/bcfg2.confHostbase``.
+Edit the hostbase options to correspond to the database you've
+initialized and copy the configuration to ``/etc/bcfg2.conf``.  To
+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'''
 
-Now it's possible to explore the Hostbase web interface.  For curiosity, you can run Django's built-in development server to take a peek.  Do this by running {{{python manage.py runserver [servername:port]}}} from your Hostbase directory.  Django will default to {{{localhost:8000}}} if no server or port is entered.  Now you can explore the web interface.  Try adding a host and a zone.  You'll see that a ".rev" zone already exists.  This is where information for reverse files will go.
+Now it's possible to explore the Hostbase web interface.  For
+curiosity, you can run Django's built-in development server to take a
+peek.  Do this by running ``python manage.py runserver
+[servername:port]`` from your Hostbase directory.  Django will
+default to ``localhost:8000`` if no server or port is entered.  Now
+you can explore the web interface.  Try adding a host and a zone.
+You'll see that a ".rev" zone already exists.  This is where
+information for reverse files will go.
 
 For production, you'll want to have this configured for Apache with mod_python.  Here is an example of how to configure Hostbase as a virtual host.
 
@@ -113,11 +127,11 @@ 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'''
 
-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
 
@@ -125,11 +139,11 @@ 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'''
 
-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
 
@@ -143,12 +157,12 @@ Bcfg2 needs a way to distribute the files generated by Hostbase.  We'll do this
        <ConfigFile 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 ``ConfigFiles`` in its bundles automatically.
 
 
 '''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
 
@@ -157,7 +171,7 @@ 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
@@ -169,8 +183,8 @@ 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.
 
 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
+ * 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.
diff --git a/doc/plugins/generators/nagiosgen.txt b/doc/plugins/generators/nagiosgen.txt
index 99e304309..026109f21 100644
--- a/doc/plugins/generators/nagiosgen.txt
+++ b/doc/plugins/generators/nagiosgen.txt
@@ -6,7 +6,9 @@
 NagiosGen
 =========
 
-This page describes the installation and use of the [http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins/NagiosGen.py NagiosGen] plugin.
+This page describes the installation and use of the `NagiosGen
+<http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins/NagiosGen.py>`_
+plugin.
 
 Update /etc/bcfg2.conf, adding NagiosGen to plugins::
 
diff --git a/doc/plugins/generators/pkgmgr.txt b/doc/plugins/generators/pkgmgr.txt
index ddd8a0792..89e67e5b7 100644
--- a/doc/plugins/generators/pkgmgr.txt
+++ b/doc/plugins/generators/pkgmgr.txt
@@ -6,7 +6,13 @@
 Pkgmgr
 ======
 
-.. note:: See [wiki:ClientTools/RPMng#PackageTagNewStyleandAttributes RPMng#PackageTagNewStyleandAttributes].''' The way of showing the architecture of the RPM has changed. The new way is "arch". The old way is "multiarch". '''This document needs to be updated and include version of Bcfg2 where change took place.'''
+.. note::
+
+    See [wiki:ClientTools/RPMng#PackageTagNewStyleandAttributes
+    RPMng#PackageTagNewStyleandAttributes].''' The way of showing the
+    architecture of the RPM has changed. The new way is "arch". The
+    old way is "multiarch". '''This document needs to be updated and
+    include version of Bcfg2 where change took place.'''
 
 The Pkgmgr plugin resolves the Abstract Configuration Entity "Package" to a package specification that the client can use to detect, verify and install the specified package.
 
@@ -37,36 +43,75 @@ PackageList Tag
 
 The PackageList Tag may have the following attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| priority || Sets the priority for packages in the package list.The high value wins. || Integer ||
-|| type || Package type that applies to all packages in the list. This value is inherited by all packages without an explicit type attribute. || (deb|rpm|blast|encap|sysv|portage|yum) ||
-|| uri || URI to prepend to filenames to fetch packages in this list. || String ||
-|| multiarch || Comma separated list of architectures that apply to all packages in this list.  Inherited by all package entries in the file that do not have this attribute explicitly. || String ||
-|| srcs || To be used with multiarch support.  Inherited by all Package entries without this attribute. || String ||
++-----------+-----------------------------------------------+----------------+
+| Name      | Description                                   | Values         |
++===========+===============================================+================+
+| priority  | Sets the priority for packages in the package | Integer        |
+|           | list. The higher value wins.                  |                |
++-----------+-----------------------------------------------+----------------+
+| type      | Package type that applies to all packages in  | deb|rpm|blast| |
+|           | the list. This value is inherited by all      | encap|sysv|    |
+|           | packages without an explicit type attribute.  | portage|yum    |
++-----------+-----------------------------------------------+----------------+
+| uri       | URI to prepend to filename sto fetch packages | String         |
+|           | in this list.                                 |                |
++-----------+-----------------------------------------------+----------------+
+| multiarch | Comma-separated list of architectures that    | String         |
+|           | apply to all packages in this list. Inherited |                |
+|           | by all package entries in the file that does  |                |
+|           | not have this attribute explicitly.           |                |
++-----------+-----------------------------------------------+----------------+
+| srcs      | To be used with multiarch support. Inherited  | String         |
+|           | by all Package entries without this attribute |                |
++-----------+-----------------------------------------------+----------------+
 
 Pkgmgr Group Tag
 ----------------
 
 The Pkgmgr Group Tag may have the following attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name  || Group Name || String ||
-|| negate || Negate group membership (is not a member of) || (True|False) ||
++--------+----------------------------------------------+------------+
+| Name   | Description                                  | Values     |
++========+==============================================+============+
+| name   | Group Name                                   | String     |
++--------+----------------------------------------------+------------+
+| negate | Negate group membership (is not a member of) | True|False |
++--------+----------------------------------------------+------------+
 
 Package Tag
 -----------
 
 The Package Tag may have the following attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name  || Package Name || String ||
-|| version || Package Version, version='auto' to install the latest version in the client's cache, or version='any' to verify that any version of the package is installed on the client || String ||
-|| file || Package file name.  Several other attributes (name, version) can be automatically defined based on regular expressions defined in the Pkgmgr plugin. || String ||
-|| simplefile || Package file name. No name parsing is performed, so no extra fields get set || String ||
-|| verify || verify='false' - do not do package verification || String ||
-|| multiarch || Comma separated list of the architectures of this package that should be installed. (Temporary Work around) || String ||
-|| srcs || File name creation rules for multiarch packages.  (Temporary Work around) || String ||
-|| type || Package type. (rpm, yum, apt,sysv,blast) || String ||
++------------+----------------------------------------------+------------+
+| Name       | Description                                  | Values     |
++============+==============================================+============+
+| name       | Package Name                                 | String     |
++------------+----------------------------------------------+------------+
+| version    | Package version, set to ``auto`` to install  | String     |
+|            | the latest version in the client's cache, or |            |
+|            | ``any`` to verify that any version of the    |            |
+|            | package is installed on the client           |            |
++------------+----------------------------------------------+------------+
+| file       | Package file name. Several other attributes  | String     |
+|            | (name, version) can be automatically defined |            |
+|            | based on regular expressions defined in the  |            |
+|            | Pkgmgr plugin.                               |            |
++------------+----------------------------------------------+------------+
+| simplefile | Package file name. No name parsing is        | String     |
+|            | performed, so no extra fields get set        |            |
++------------+----------------------------------------------+------------+
+| verify     | Whether package verification should be done  | True|False |
++------------+----------------------------------------------+------------+
+| multiarch  | Comma-separated list of the architectures of | String     |
+|            | this package that should be installed.       |            |
+|            | (Temporary work-around)                      |            |
++------------+----------------------------------------------+------------+
+| srcs       | File name creation rules for multiarch       | String     |
+|            | packages. (Temporary work-around)            |            |
++------------+----------------------------------------------+------------+
+| type       | Package type (rpm, yum, apt, sysv, blast)    | String     |
++------------+----------------------------------------------+------------+
 
 Client Tag
 ----------
@@ -78,9 +123,13 @@ The Client Tag is used in a PackageList for selecting the package entries to inc
 
 The Client Tag may have the following attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name  || Client Name || String ||
-|| negate || Negate client selection (if not client name) || (True|False) ||
++--------+----------------------------------------------+------------+
+| Name   | Description                                  | Values     |
++========+==============================================+============+
+| name   | Client Name                                  | String     |
++--------+----------------------------------------------+------------+
+| negate | Negate client selection (if not client name) | True|False |
++--------+----------------------------------------------+------------+
 
 Pkgmgr Directory
 ================
diff --git a/doc/plugins/generators/tcheetah.txt b/doc/plugins/generators/tcheetah.txt
index 4c3a8972f..829e25901 100644
--- a/doc/plugins/generators/tcheetah.txt
+++ b/doc/plugins/generators/tcheetah.txt
@@ -6,21 +6,31 @@
 TCheetah
 ========
 
-This document reflects the [source:trunk/bcfg2/src/lib/Server/Plugins/TCheetah.py TCheetah plugin] in bcfg2 0.8.4 and later.
+This document reflects the ``TCheetah`` plugin.
 
-The TCheetah plugin allows you to use the [http://www.cheetahtemplate.org/ cheetah templating system] to create files, instead of the various diff-based methods offered by the Cfg plugin. It also allows you to include the results of probes executed on the client in the created files.
+The ``TCheetah`` plugin allows you to use the `cheetah templating system
+<http://www.cheetahtemplate.org/>`_ to create files, instead of the
+various diff-based methods offered by the ``Cfg`` plugin. It also allows
+you to include the results of probes executed on the client in the
+created files.
 
-To begin, you will need to download and install the Cheetah templating engine from [http://www.cheetahtemplate.org/].  Once it is installed, you can enable it by adding `TCheetah` to the `plugins` line in `/etc/bcfg2.conf` on your Bcfg server.
-For example::
+To begin, you will need to download and install the Cheetah templating
+engine from http://www.cheetahtemplate.org/.  Once it is installed,
+you can enable it by adding ``TCheetah`` to the ``plugins`` line in
+``/etc/bcfg2.conf`` on your Bcfg server.  For example::
 
     generators = SSHbase,Cfg,Pkgmgr,Svcmgr,Rules,TCheetah
 
-The TCheetah plugin makes use of a Cfg-like directory structure located in in a `TCheetah` subdirectory of your repository, usually `/var/lib/bcfg2/TCheetah`. Each file has a directory containing two files, `template` and `info`. The template is a standard Cheetah template with two additions:
+The ``TCheetah`` plugin makes use of a ``Cfg``-like directory structure
+located in in a ``TCheetah`` subdirectory of your repository, usually
+``/var/lib/bcfg2/TCheetah``. Each file has a directory containing two
+files, ``template`` and ``info``. The template is a standard Cheetah
+template with two additions:
 
 * `self.metadata` is the client's metadata
 * `self.properties` is an xml document of unstructured data
 
-The `info` file is formatted like `:info` files from Cfg.
+The ``info`` file is formatted like ``:info`` files from Cfg.
 
 Mostly, people will want to use client metadata.
 
@@ -38,14 +48,16 @@ The following variables are available for self.metadata:
 * uuid
 * password
 
-self.metadata is an instance of the class ClientMetadata of file [http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins/Metadata.py Bcfg2/Server/Plugins/Metadata.py].
+self.metadata is an instance of the class ClientMetadata of file `Bcfg2/Server/Plugins/Metadata.py <http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins/Metadata.py>`_.
 
 self.properties
 ===============
 
-properties is a python [http://codespeak.net/lxml/ ElementTree] object, loaded from the data in /var/lib/bcfg2/etc/properties.xml.  That file should have a Properties node at its root.
+properties is a python `ElementTree <http://codespeak.net/lxml/>`_
+object, loaded from the data in ``/var/lib/bcfg2/etc/properties.xml``.
+That file should have a ``Properties`` node at its root.
 
-Example properties.xml:
+Example ``properties.xml``:
 
 .. code-block:: xml
 
diff --git a/doc/plugins/generators/tgenshi.txt b/doc/plugins/generators/tgenshi.txt
index 36b0dd8ea..bc0de8cbc 100644
--- a/doc/plugins/generators/tgenshi.txt
+++ b/doc/plugins/generators/tgenshi.txt
@@ -8,7 +8,11 @@ TGenshi
 
 This page documents the TGenshi plugin. This plugin works with version 0.4 and newer of the genshi library.
 
-The TGenshi plugin allows you to use the [http://genshi.edgewall.org Genshi] templating system to create files, instead of the various diff-based methods offered by the Cfg plugin. It also allows you to include the results of probes executed on the client in the created files.
+The TGenshi plugin allows you to use the `Genshi
+<http://genshi.edgewall.org>`_ templating system to create files,
+instead of the various diff-based methods offered by the Cfg
+plugin. It also allows you to include the results of probes executed
+on the client in the created files.
 
 To begin, you will need to download and install the Genshi templating engine.
 
@@ -16,15 +20,24 @@ To install on CentOS or RHEL 5, run::
 
     sudo yum install python-genshi
 
-Once it is installed, you can enable it by adding TGenshi to the generators line in /etc/bcfg2.conf on your Bcfg server. For example::
+Once it is installed, you can enable it by adding ``TGenshi`` to the
+generators line in ``/etc/bcfg2.conf`` on your Bcfg server. For example::
 
     generators = SSHbase,Cfg,Pkgmgr,Svcmgr,Rules,TGenshi
 
-The TGenshi plugin makes use of a Cfg-like directory structure located in in a TGenshi subdirectory of your repository, usually `/var/lib/bcfg2/TGenshi`. Each file has a directory containing two file types, template and info. Templates are named according to the genshi format used; template.txt uses the genshi text format, and template.xml uses the XML format.
+The TGenshi plugin makes use of a Cfg-like directory structure located in in a TGenshi subdirectory of your repository, usually ``/var/lib/bcfg2/TGenshi``. Each file has a directory containing two file types, template and info. Templates are named according to the genshi format used; template.txt uses the genshi text format, and template.xml uses the XML format.
 
-If used with Genshi 0.5 or later the plugin also supports the [http://genshi.edgewall.org/wiki/Documentation/0.5.x/text-templates.html new style] text template format for files named template.newtxt. One of the advantages of the new format is that it does not use # as a command delimiter, making it easier to utilize for configuration files that use # as a comment character.
+If used with Genshi 0.5 or later the plugin also supports the `new
+style
+<http://genshi.edgewall.org/wiki/Documentation/0.5.x/text-templates.html>`_
+text template format for files named template.newtxt. One of the
+advantages of the new format is that it does not use # as a command
+delimiter, making it easier to utilize for configuration files that
+use # as a comment character.
 
-Only one template format may be used per file served. Info files are identical to those used in Cfg, and info.xml files are supported.
+Only one template format may be used per file served. Info files are
+identical to those used in ``Cfg``, and ``info.xml`` files are
+supported.
 
 Inside of templates
 ===================
@@ -32,7 +45,9 @@ Inside of templates
 * metadata is the client's metadata
 * properties.properties is an xml document of unstructured data
 
-See the genshi [http://genshi.edgewall.org/wiki/Documentation documentation] for examples of Genshi syntax.
+See the genshi `documentation
+<http://genshi.edgewall.org/wiki/Documentation>`_ for examples of
+Genshi syntax.
 
 Examples
 ========
@@ -44,7 +59,6 @@ Examples: Old Genshi Syntax
 
 Genshi's web pages recommend against using this syntax, as it may disappear from future releases.
 
-
 Group Negation
 --------------
 
@@ -72,4 +86,9 @@ FAQs
 
 '''Question:''' How do I escape the $ (dollar sign) in a TGenshi text template? For example, if I want to include SVN (subversion) keywords like $Id$ or $HeadURL$ in TGenshi-generated files, or am templating a bourne shell (sh/bash) script or Makefile (make).
 
-'''Answer:''' Use $$ (double dollar sign) to output a literal $ (dollarsign) in a TGenshi text template. So instead of $Id$, you'd use $$Id$$. See also Genshi tickets [http://genshi.edgewall.org/ticket/282 #282: Document $$ escape convention] and [http://genshi.edgewall.org/ticket/283 #283: Allow for redefinition of template syntax per-file].
+'''Answer:''' Use $$ (double dollar sign) to output a literal $
+(dollarsign) in a TGenshi text template. So instead of $Id$, you'd use
+$$Id$$. See also Genshi tickets `#282: Document $$ escape convention
+<http://genshi.edgewall.org/ticket/282>`_ and `#283: Allow for
+redefinition of template syntax per-file
+<http://genshi.edgewall.org/ticket/283>`_.
diff --git a/doc/plugins/grouping/metadata.txt b/doc/plugins/grouping/metadata.txt
index b82f98e28..14ada3f7a 100644
--- a/doc/plugins/grouping/metadata.txt
+++ b/doc/plugins/grouping/metadata.txt
@@ -39,36 +39,69 @@ Clients Tag
 
 The Clients tag has the following possible attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| version || Client schema version || String ||
++---------+-----------------------+--------+
+| Name    | Description           | Values |
++=========+=======================+========+
+| version | Client schema version | String |
++---------+-----------------------+--------+
 
 Client Tag
 ----------
 
-Each entry in clients.xml '''must''' have the following properties:
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name || Host name of client.  This needs do be the name (possibly a FQDN) returned by a reverse lookup on the connecting IP address. || String ||
-|| profile || Profile group name to associate this client with || String ||
+Each entry in clients.xml **must** have the following properties:
 
-Additionally, the following properties can be specified:
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| Alias || Alternative name and address for the client || XML Element ||
-|| address || Establishes an extra ip address that resolves to this client || ip address ||
-|| location || Requires requests to come from an IP address that matches the client record || fixed|floating ||
-|| password  || Establishes a per-node password that can be used instead of the global password || String ||
-|| pingable || If the client is pingable (deprecated; for old reporting system) || (Y|N) ||
-|| pingtime || Last time the client was pingable (deprecated; for old reporting system) || String ||
-|| secure || Requires the use of the per-client password for this client || true|false ||
-|| uuid || Establishes a per-node name that can be used to bypass dns-based client resolution || String ||
++---------+---------------------------------------+--------+
+| Name    | Description                           | Values |
++=========+=======================================+========+
+| name    | Host name of client. This needs to be | String |
+|         | the name (possibly a FQDN) returned   |        |
+|         | by a reverse lookup on the connecting |        |
+|         | IP address.                           |        |
++---------+---------------------------------------+--------+
+| profile | Profile group name to associate this  | String |
+|         | client with.                          |        |
++---------+---------------------------------------+--------+
 
+Additionally, the following properties can be specified:
 
-For detailed information on client authentication see [wiki:Authentication]
++----------+----------------------------------------+----------------+
+| Name     | Description                            | Values         |
++==========+========================================+================+
+| Alias    | Alternative name and address for the   | XML Element    |
+|          | client.                                |                |
++----------+----------------------------------------+----------------+
+| address  | Establishes an extra IP address that   | ip address     |
+|          | resolves to this client.               |                |
++----------+----------------------------------------+----------------+
+| location | Requires requests to come from an IP   | fixed|floating |
+|          | address that matches the client        |                |
+|          | record.                                |                |
++----------+----------------------------------------+----------------+
+| password | Establishes a per-node password that   | String         |
+|          | can be used instead of the global      |                |
+|          | password.                              |                |
++----------+----------------------------------------+----------------+
+| pingable | If the client is pingable (deprecated; | Y|N            |
+|          | for old reporting system)              |                |
++----------+----------------------------------------+----------------+
+| pingtime | Last time the client was pingable      | String         |
+|          | (deprecated; for old reporting system) |                |
++----------+----------------------------------------+----------------+
+| secure   | Requires the use of the per-client     | true|false     |
+|          | password for this client.              |                |
++----------+----------------------------------------+----------------+
+| uuid     | Establishes a per-node name that can   | String         |
+|          | be used to bypass dns-based client     |                |
+|          | resolution.                            |                |
++----------+----------------------------------------+----------------+
+
+For detailed information on client authentication see :ref:`authentication`
 
 Metadata/groups.xml
 -------------------
 
-The Metadata/groups.xml file contains Group and Profile definitions. Here's a simple
-Metadata/groups.xml file:
+The ``Metadata/groups.xml`` file contains Group and Profile
+definitions. Here's a simple ``Metadata/groups.xml`` file:
 
 .. code-block:: xml
 
@@ -93,10 +126,10 @@ Metadata/groups.xml file:
     </Groups>
 
 
-Nested/chained groups definitions are conjunctive (logical and). For instance, in
-the above example, a client associated with the Profile Group 'mail-server' is
-also a member of the apache-server, rhel-as-4-x86, nfs-client, server and rhel
-groups.
+Nested/chained groups definitions are conjunctive (logical and). For
+instance, in the above example, a client associated with the Profile
+Group ``mail-server`` is also a member of the ``apache-server``,
+``rhel-as-4-x86``, ``nfs-client``, ``server`` and ``rhel`` groups.
 
 Groups describe clients in terms for abstract, disjoint aspects. Groups can be
 combined to form complex descriptions of clients that use configuration commonality
@@ -108,31 +141,65 @@ Metadata Groups Tag
 
 The Groups tag has the following possible attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| version || Group schema version || String ||
-|| origin || URL of master version (for common repo) || String ||
-|| revision || Master version control revision || String ||
++----------+---------------------------------+--------+
+| Name     | Description                     | Values |
++==========+=================================+========+
+| version  | Group schema version            | String |
++----------+---------------------------------+--------+
+| origin   | URL of master version           | String |
+|          | (for common repository)         |        |
++----------+---------------------------------+--------+
+| revision | Master version control revision | String |
++----------+---------------------------------+--------+
 
 Metadata Group Tag
 ------------------
 
 The Group Tag has the following possible attributes:
 
-|| '' '''Name''' '' || '' '''Description''' '' || '' '''Values''' '' ||
-|| name || Name of the group || String ||
-|| profile || If a client can be directly associated with this group || (True|False*) ||
-|| public || If a client can freely associate itself with this group.  For use with bcfg2 -p option on the client. || (True|False*) ||
-|| toolset || Describes which client-side logic should be used to make configuration changes || (rh|debian|solaris|aix|auto|gentoo) ||
-|| category || A group can only contain one instance of a group in any category. This provides the basis for representing groups which are conjugates of one another in a rigorous way. It also provides the basis for negation. || String ||
-|| default || Set as the profile to use for clients that are not associated with a profile in clients.xml. || (True|False*) ||
-|| comment || English text description of group || String ||
++----------+------------------------------------------+--------------+
+| Name     | Description                              | Values       |
++==========+==========================================+==============+
+| name     | Name of the group                        | String       |
++----------+------------------------------------------+--------------+
+| profile  | If a client can be directly associated   | True|False   |
+|          | with this group                          |              |
++----------+------------------------------------------+--------------+
+| public   | If a client can freely associate itself  | True|False   |
+|          | with this group. For use with the        |              |
+|          | *bcfg2 -p* option on the client.         |              |
++----------+------------------------------------------+--------------+
+| toolset  | Describes which client-side logic should | rh|debian|   |
+|          | be used to make configuration changes    | solaris|aix| |
+|          |                                          | auto|gentoo  |
++----------+------------------------------------------+--------------+
+| category | A group can only contain one instance of | String       |
+|          | a group in any one category. This        |              |
+|          | provides the basis for representing      |              |
+|          | groups which are conjugates of one       |              |
+|          | another in a rigorous way. It also       |              |
+|          | provides the basis for negation.         |              |
++----------+------------------------------------------+--------------+
+| default  | Set as the profile to use for clients    | True|False   |
+|          | that are not associated with a profile   |              |
+|          | in ``clients.xml``                       |              |
++----------+------------------------------------------+--------------+
+| comment  | English text description of group        | String       |
++----------+------------------------------------------+--------------+
 
 Groups can also contain other groups and bundles.
 
 Use of XInclude
 ===============
 
-[http://www.w3.org/TR/xinclude/ XInclude] is a W3C specification for the inclusion of external XML documents into XML source files. Much like the use of #include in C, this allows complex definitions to be split into smaller, more manageable pieces. As of bcfg2-0.9.0pre1, the Metadata plugin supports the use of XInclude specifications to split the clients.xml and groups.xml files. This mechanism allows the following specification to produce useful results:
+`XInclude <http://www.w3.org/TR/xinclude/>`_ is a W3C specification
+for the inclusion of external XML documents into XML source
+files. Much like the use of ``#include`` in C, this allows complex
+definitions to be split into smaller, more manageable pieces. As of
+bcfg2-0.9.0pre1, the `Metadata`_ plugin supports the use of XInclude
+specifications to split the ``clients.xml`` and ``groups.xml``
+files. This mechanism allows the following specification to produce
+useful results:
 
 .. code-block:: xml
 
@@ -141,9 +208,13 @@ Use of XInclude
      <xi:include href="their-groups.xml" />
     </Groups>
 
-Each of the included groups files has the same format. These files are properly validated by bcfg2-repo-validate. This mechanism is useful for composing group definitions from multiple sources, or setting different permissions in an svn repository.
+Each of the included groups files has the same format. These files are
+properly validated by ``bcfg2-repo-validate``. This mechanism is
+useful for composing group definitions from multiple sources, or
+setting different permissions in an svn repository.
 
 Probes
 ======
 
-The metadata plugin includes client-side probing functionality. This is fully documented [wiki:Probes here].
+The metadata plugin includes client-side probing functionality. This
+is fully documented :ref:`here <plugins-probes>`.
diff --git a/doc/plugins/structures/bundler.txt b/doc/plugins/structures/bundler.txt
index 86f3dbf08..694698c55 100644
--- a/doc/plugins/structures/bundler.txt
+++ b/doc/plugins/structures/bundler.txt
@@ -44,23 +44,41 @@ The following is an annotated copy of a 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)
 
-|| '' '''Group''' '' || '' '''Entry''' '' ||
-|| all || /etc/ssh/ssh_host_dsa_key ||
-|| all || /etc/ssh/ssh_host_rsa_key ||
-|| all || /etc/ssh/ssh_host_dsa_key.pub ||
-|| all || /etc/ssh/ssh_host_rsa_key.pub ||
-|| all || /etc/ssh/ssh_host_key ||
-|| all || /etc/ssh/ssh_host_key.pub ||
-|| all || /etc/ssh/sshd_config ||
-|| all || /etc/ssh/ssh_config ||
-|| all || /etc/ssh/ssh_known_hosts ||
-|| rpm || Package openssh ||
-|| rpm || Package openssh-askpass ||
-|| rpm || Service sshd ||
-|| rpm and fedora || Package openssh-server ||
-|| rpm and fedora and not fc4 || Package openssh-clients ||
-|| deb || Package ssh ||
-|| deb || Service ssh ||
++----------------------------+-------------------------------+
+| Group                      | Entry                         |
++============================+===============================+
+| all                        | /etc/ssh/ssh_host_dsa_key     |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_host_rsa_key     |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_host_dsa_key.pub |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_host_rsa_key.pub |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_host_key         |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_host_key.pub     |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/sshd_config          |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_config           |
++----------------------------+-------------------------------+
+| all                        | /etc/ssh/ssh_known_hosts      |
++----------------------------+-------------------------------+
+| rpm                        | Package openssh               |
++----------------------------+-------------------------------+
+| rpm                        | Package openssh-askpass       |
++----------------------------+-------------------------------+
+| rpm                        | Service sshd                  |
++----------------------------+-------------------------------+
+| rpm and fedora             | Package openssh-server        |
++----------------------------+-------------------------------+
+| rpm and fedora and not fc4 | Package openssh-clients       |
++----------------------------+-------------------------------+
+| deb                        | Package ssh                   |
++----------------------------+-------------------------------+
+| deb                        | Service ssh                   |
++----------------------------+-------------------------------+
 
 Genshi templates
 ================
@@ -72,7 +90,9 @@ Motivation
 
 Static Bundles have served us relatively well, but have a relatively weak set of interal per-client differentiation mechanisms. In static Bundles, the group hierarchy (from the perspective of the current client) is available for use via boolean constraints with negation. This notion does not mesh well with the use of Probes, which can result in freeform data. In the presence of probe results, clients can have a wide array of data, and rendering down to a boolean logic may not always be desirable. Moreover, while static Bundles allow entry inclusion or exclusion based on group memberships, they do not allow programatic entry rendering. Hence, Genshi templates not only provide more control options, but it also provide the ability to perform new entry rendering operations.
 
-The [http://genshi.edgewall.org/ Genshi templating system] is used internally.
+The `Genshi templating system`_ is used internally.
+
+.. _Genshi templating system: http://genshi.edgewall.org/
 
 Use
 ---