doc: Finish merging remaining documentation updates

Signed-off-by: Sol Jerome <sol.jerome@gmail.com>

15 files changed, 136 insertions, 114 deletions

diff --git a/doc/appendix/configuration/mrepo.txt b/doc/appendix/configuration/mrepo.txt
index 0633af98e..309cd6779 100644
--- a/doc/appendix/configuration/mrepo.txt
+++ b/doc/appendix/configuration/mrepo.txt
@@ -15,7 +15,6 @@ takes care of setting up the ISO files, downloading the RPMs,
 configuring HTTP access and providing PXE/TFTP resources for remote
 network installations.
 
-
 Sample mrepo configuration
 --------------------------
 
@@ -66,6 +65,6 @@ Sample mrepo configuration
 Update the repositories
 -----------------------
 
-To update your local repository, just lauch the following command ::
+::
 
     mrepo -ug
diff --git a/doc/appendix/contributors.txt b/doc/appendix/contributors.txt
index 9f2c18115..eaf4aa29a 100644
--- a/doc/appendix/contributors.txt
+++ b/doc/appendix/contributors.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _AUTHORS: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/AUTHORS
+.. _AUTHORS: http://trac.mcs.anl.gov/projects/bcfg2/browser/AUTHORS
 .. _MCS: http://www.mcs.anl.gov/
 
 .. _appendix-contributors:
diff --git a/doc/appendix/guides/authentication.txt b/doc/appendix/guides/authentication.txt
index 13b797625..0a324b718 100644
--- a/doc/appendix/guides/authentication.txt
+++ b/doc/appendix/guides/authentication.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _guide-authentication:
+.. _appendix-guides-authentication:
 
 ==============
 Authentication
@@ -14,7 +14,7 @@ Scenarios
    Default settings work well; machines do not float, and a per-client
    password is not required.
 
-2. :ref:`NAT Howto nat_howto`
+2. :ref:`appendix-guides-nat_howto`
 
  * Build client records in advance with ``bcfg2-admin``, setting a uuid
    for each new client.
@@ -33,7 +33,7 @@ Building bcfg2.conf automatically
 =================================
 
 This is a TCheetah template that automatically constructs per-client
-`bcfg2.conf` from the per-client metadata::
+bcfg2.conf from the per-client metadata::
 
     [communication]
     protocol = xmlrpc/ssl
@@ -43,14 +43,14 @@ This is a TCheetah template that automatically constructs per-client
     #if $self.metadata.password != None
     password = $self.metadata.password
     #else
-    password = my-password-foobar
+    password = my-password-foobat
     #end if
 
     [components]
     bcfg2 = https://localhost:6789
 
 In this setup, this will cause any clients that have uuids established
-to be set to use them in `bcfg2.conf`. It will also cause any clients
+to be set to use them in ``bcfg2.conf``. It will also cause any clients
 with passwords set to use them instead of the global password.
 
 How Authentication Works
diff --git a/doc/appendix/guides/centos.txt b/doc/appendix/guides/centos.txt
index 91c1f268f..1e3c90156 100644
--- a/doc/appendix/guides/centos.txt
+++ b/doc/appendix/guides/centos.txt
@@ -2,7 +2,7 @@
 
 .. _EPEL: http://fedoraproject.org/wiki/EPEL
 
-.. _guide-centos:
+.. _appendix-guides-centos:
 
 =====================
 Quickstart for CentOS
diff --git a/doc/appendix/guides/converging_rhel5.txt b/doc/appendix/guides/converging_rhel5.txt
index 9d508e5e4..7581d307f 100644
--- a/doc/appendix/guides/converging_rhel5.txt
+++ b/doc/appendix/guides/converging_rhel5.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _unsorted-converging_rhel5:
+.. _appendix-guides-converging_rhel5:
 
 ======================================
 Converging on Verification with RHEL 5
@@ -18,25 +18,29 @@ Unmanaged entries
 
 * Package (top-level)
 
- #. Enable the "Packages" plugin in {{{/etc/bcfg2.conf}}}, and configure the Yum repositories in {{{/var/lib/bcfg2/Packages/config.xml}}}.
+ #. Enable the "Packages" plugin in ``/etc/bcfg2.conf``, and configure
+    the Yum repositories in ``/var/lib/bcfg2/Packages/config.xml``.
  #. If a package is unwanted, remove it::
 
         sudo yum remove PACKAGE
 
- #. Otherwise, add {{{<Package name="PACKAGE" />}}} to the Base or Bundler configuration.
+ #. Otherwise, add ``<Package name="PACKAGE" />`` to the Base or Bundler configuration.
 
 * Package (dependency)
 
- #. Ensure the Yum repository sources configured in {{{/var/lib/bcfg2/Packages/config.xml}}} are correct.
- #. Ensure the Yum repositories themselves are up-to-date with the main package and dependencies.
+ #. Ensure the Yum repository sources configured in
+    ``/var/lib/bcfg2/Packages/config.xml`` are correct.
+ #. Ensure the Yum repositories themselves are up-to-date with the main
+    package and dependencies.
  #. Rebuild the Packages plugin cache::
 
         bcfg2-admin xcmd Packages.Refresh
 
 * Service
 
- #. Add {{{<Service name="SERVICE" />}}} to the Base or Bundler configuration.
- #. Add {{{<Service name="SERVICE" status="on" type="chkconfig" />}}} to {{{/var/lib/bcfg2/Rules/services.xml}}}.
+ #. Add ``<Service name="SERVICE" />`` to the Base or Bundler configuration.
+ #. Add ``<Service name="SERVICE" status="on" type="chkconfig" />`` to
+    ``/var/lib/bcfg2/Rules/services.xml``.
 
 Incorrect entries
 =================
@@ -46,13 +50,17 @@ For a "Package"
 
 * Failed RPM verification
 
- #. Run {{{rpm -V PACKAGE}}}
- #. Add configuration files (the ones with "c" next to them in the verification output) to {{{/var/lib/bcfg2/Cfg/}}}.
+ #. Run ``rpm -V PACKAGE``
+ #. Add configuration files (the ones with "c" next to them in the
+    verification output) to ``/var/lib/bcfg2/Cfg/``.
 
-  * For example, {{{/etc/motd}}} to {{{/var/lib/bcfg2/Cfg/etc/motd/motd}}}. Yes, there is an extra directory level named after the file.
+  * For example, ``/etc/motd`` to ``/var/lib/bcfg2/Cfg/etc/motd/motd``.
+    Yes, there is an extra directory level named after the file.
 
- #. Specify configuration files as {{{<Path name='PATH' />}}} in the Base or Bundler configuration.
- #. Add directories to {{{/var/lib/bcfg2/Rules/directories.xml}}}. For example:
+ #. Specify configuration files as ``<Path name='PATH' />`` in the Base
+    or Bundler configuration.
+ #. Add directories to ``/var/lib/bcfg2/Rules/directories.xml``. For
+    example:
 
     .. code-block:: xml
 
@@ -65,8 +73,9 @@ For a "Package"
 
  * Option A: Explicitly list the instances
 
-  #. Drop the {{{<Package />}}} from the Base or Bundler configuration.
-  #. Add an explicit {{{<BoundPackage>}}} and {{{<Instance />}}} configuration to a new Bundle, like the following:
+  #. Drop the ``<Package />`` from the Base or Bundler configuration.
+  #. Add an explicit ``<BoundPackage>`` and ``<Instance />`` configuration
+     to a new Bundle, like the following:
 
      .. code-block:: xml
 
@@ -78,22 +87,25 @@ For a "Package"
            </BoundPackage>
          </Bundle>
 
-  #. Add the bundle to the applicable groups in {{{/var/lib/bcfg2/Metadata/groups.xml}}}.
+  #. Add the bundle to the applicable groups in
+     ``/var/lib/bcfg2/Metadata/groups.xml``.
 
  * Option B: Disable verification of the package
 
-  #. Add {{{pkg_checks="false"}}} to the {{{<Package />}}} tag.
+  #. Add ``pkg_checks="false"`` to the ``<Package />`` tag.
 
 For a "Path"
 -------------------
 
- * Unclear verification problem (no details from BCFG2)
+ * Unclear verification problem (no details from Bcfg2)
 
-  1. Run {{{bcfg2 -vqI}}} to see detailed verification issues (but deny any suggested actions).
+  1. Run ``bcfg2 -vqI`` to see detailed verification issues (but deny
+     any suggested actions).
 
  * Permissions mismatch
 
-  1. Create an {{{info.xml}}} file in the same directory as the configuration file. Example:
+  1. Create an ``info.xml`` file in the same directory as the
+     configuration file. Example:
 
      .. code-block:: xml
 
diff --git a/doc/appendix/guides/fedora.txt b/doc/appendix/guides/fedora.txt
index f3a5a3929..d8d3b1b34 100644
--- a/doc/appendix/guides/fedora.txt
+++ b/doc/appendix/guides/fedora.txt
@@ -470,8 +470,3 @@ The first commit can be the empty or the allready populated directory::
 While running ``bcfg2-info`` the following line will show up::
 
    Initialized git plugin with git directory = /var/lib/bcfg2/.git
-
-
-
-
-
diff --git a/doc/appendix/guides/gentoo.txt b/doc/appendix/guides/gentoo.txt
index 023e6ac24..e818364ce 100644
--- a/doc/appendix/guides/gentoo.txt
+++ b/doc/appendix/guides/gentoo.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _guide-gentoo:
+.. _appendix-guides-gentoo:
 
 ======
 Gentoo
@@ -23,8 +23,8 @@ should still work provided that you have a reasonably up to date Python;
 try adding `app-admin/bcfg2 ~*` to your `/etc/portage/package.keywords`
 file.
 
-If you don’t use portage to install Bcfg2, you’ll want to make sure you
-have all the prerequisites installed first. For a server, you’ll need:
+If you don't use portage to install Bcfg2, you'll want to make sure you
+have all the prerequisites installed first. For a server, you'll need:
 
 * ``app-admin/gamin`` or ``app-admin/fam``
 * ``dev-python/lxml``
@@ -37,7 +37,7 @@ Package Repository
 ==================
 
 You’ll need (to make) at least one archive of binary packages. The
-Portage driver calls ``emerge`` with the ``–getbinpkgonly`` option. See
+Portage driver calls ``emerge`` with the ``-getbinpkgonly`` option. See
 :manpage:`make.conf(5)` and :manpage:`emerge(1)` manpages, specifically
 the *PORTAGE_BINHOST* environment variable.
 
@@ -52,7 +52,7 @@ present state of the system by using the quickpkg utility. For example:
 
     for pkg in `equery -q l` ; do quickpkg "=$pkg" ; done
 
-…will leave you with a complete archive of all the packages on your
+...will leave you with a complete archive of all the packages on your
 system in ``/usr/portage/packages/All``, which you can then move to your
 ftp server.
 
@@ -60,7 +60,7 @@ Cataloging Packages In Your Repository
 --------------------------------------
 
 Once you have a set of packages, you will need to create a catalog for
-them in ``/var/lib/bcfg2/Pkgmgr``. Here’s a template:
+them in ``/var/lib/bcfg2/Pkgmgr``. Here's a template:
 
 .. code-block:: xml
 
@@ -70,7 +70,7 @@ them in ``/var/lib/bcfg2/Pkgmgr``. Here’s a template:
       </Group>
     </PackageList>
 
-…and a partially filled-out example, for our local Gentoo/VMware build:
+...and a partially filled-out example, for our local Gentoo/VMware build:
 
 .. code-block:: xml
 
@@ -82,17 +82,17 @@ them in ``/var/lib/bcfg2/Pkgmgr``. Here’s a template:
       </Group>
     </PackageList>
 
-The `<Group>` name (in our example, “gentoo-200701-vmware”) should
+The `<Group>` name (in our example, "gentoo-200701-vmware") should
 be included by any host which will draw its packages from this list. Our
 collection of packages for this class of machines is at the listed URI,
 and we only have one collection of packages for this batch of machines so
-in our case the `priority` doesn’t really matter, we’ve set it to `0`.
+in our case the `priority` doesn’t really matter, we've set it to `0`.
 
 Notice that package name fields are in `CAT/TITLE` format.
 
 Here is a hack which will generate a list of Package lines from
-a system’s database of installed packages, especially useful in
-conjunction with the `quickpkg` example above:
+a system's database of installed packages, especially useful in
+conjunction with the ``quickpkg`` example above:
 
 .. code-block:: sh
 
@@ -123,14 +123,14 @@ Pitfalls
 Package Verification Issues
 ---------------------------
 
-As of this writing (2007/01/31), we’re aware of a number of packages
+As of this writing (2007/01/31), we're aware of a number of packages
 marked stable in the Gentoo x86 tree which, for one reason or another,
-consistently fail to verify cleanly under `equery check`. In some cases
-(pam, openldap), files which don’t (ever) exist on the system are
+consistently fail to verify cleanly under ``equery check``. In some cases
+(pam, openldap), files which don't (ever) exist on the system are
 nonetheless recorded in the package database; in some (python, Bcfg2,
 ahem), whole classes of files (.pyc and .pyo files) consistently fail
 their md5sum checks; and in others, the problem appears to be a
-discrepancy in the way that symlinks are created vs. the way they’re
+discrepancy in the way that symlinks are created vs. the way they're
 recorded in the database. For example, in the OpenSSH package,
 /usr/bin/slogin is a symlink to ./ssh, but equery expects it to point to
 an unadorned ssh. An analogous situation exists with their manpages,
@@ -147,13 +147,13 @@ leading to noise like this::
 We can ignore the lines for ``ssh_config`` and ``sshd_config``; those will
 be caught by Bcfg2 as registered config files and handled appropriately.
 
-Because Bcfg2 relies on the client system’s native package reporting
+Because Bcfg2 relies on the client system's native package reporting
 tool to judge the state of installed packages, complaints like these
 about trivial or intractable verification failures can trigger unnecessary
 bundle reinstalls when the Bcfg2 client runs. Bcfg2 will catch on after a
-pass or two that the situation isn’t getting any better with repeated
-package installs, stop trying, and list those packages as “bad” in
-the client system’s statistics.
+pass or two that the situation isn't getting any better with repeated
+package installs, stop trying, and list those packages as "bad" in
+the client system's statistics.
 
 Aside from filing bugs with the Gentoo package maintainers, your narrator
 has been unable to come up with a good approach to this. Maybe write a
@@ -171,7 +171,7 @@ during normal runtime. This can lead to trouble during verification and
 package installation, for example when ``/boot/grub/grub.conf`` turns
 up missing. The simplest way around this might just be to ensure that
 ``/boot`` is mounted whenever you run Bcfg2, possibly wrapping Bcfg2
-in a script for the purpose. I’ve also thought about adding *Action*
+in a script for the purpose. I've also thought about adding *Action*
 clauses to bundles for grub and our kernel packages, which would mount
 ``/boot`` before the bundle installs and unmount it afterward, but this
-doesn’t get around the problem of those packages flunking verification.
+doesn't get around the problem of those packages flunking verification.
diff --git a/doc/appendix/guides/nat_howto.txt b/doc/appendix/guides/nat_howto.txt
index 131c0c533..818d3e644 100644
--- a/doc/appendix/guides/nat_howto.txt
+++ b/doc/appendix/guides/nat_howto.txt
@@ -1,56 +1,86 @@
 .. -*- mode: rst -*-
 
-.. _unsorted-nat_howto:
+.. _appendix-guides-nat_howto:
 
 =========
 NAT HOWTO
 =========
 
-This page describes how to setup bcfg2 to properly function with a collection of clients behind NAT. It describes the issues, how the underlying portions of the bcfg2 system function, and how to correctly setup client metadata to cope with this environment.
+This page describes how to setup Bcfg2 to properly function with a
+collection of clients behind NAT. It describes the issues, how the
+underlying portions of the Bcfg2 system function, and how to correctly
+setup client metadata to cope with this environment.
 
 Issues
 ======
 
-Bcfg2, by default, uses ip address lookup to determine the identity of a client that has connected. This process doesn't work properly in the case of NATted hosts, because all requests from these clients come from the same external address when connecting to the server.
+Bcfg2, by default, uses ip address lookup to determine the identity of
+a client that has connected. This process doesn't work properly in the
+case of NAT'ed hosts, because all requests from these clients come from
+the same external address when connecting to the server.
 
-These client identification issues will manifest themselves in a number of ways:
+These client identification issues will manifest themselves in a number
+of ways:
 
 * Inability to setup discrete clients with different profiles
 * Incorrect sharing of probe results across clients in the same NAT pool
-* Inability to bootstrap clients properly when client data is not predefined
+* Inability to bootstrap clients properly when client data is not
+  predefined
 
 Architectural Issues
 ====================
 
-Client identification is performed as the beginning of each client/server interaction. As of 0.9.3pre3, client identification via IP address can be completely short-circuited through the use of a client uuid. Setup of client uuids requires actions of both the client and server. On the server side, the client uuid must be added to the client record in Metadata/clients.xml. This attribute allows the server to use the user part of the authentication to resolve the client's metadata. Also, either the location attribute should be set to floating, or the IP address of the NAT must be reflected in the address attribute.
-Once added, the Client entry in clients.xml will look like:
+Client identification is performed at the beginning of each client/server
+interaction. As of 0.9.3, client identification via IP address can be
+completely short-circuited through the use of a client uuid. Setup of
+client uuids requires actions of both the client and server. On the
+server side, the client uuid must be added to the client record in
+``Metadata/clients.xml``. This attribute allows the server to use the
+user part of the authentication to resolve the client's metadata. Also,
+either the location attribute should be set to floating, or the IP address
+of the NAT must be reflected in the address attribute.  Once added,
+the Client entry in clients.xml will look something like this:
 
 .. code-block:: xml
 
     <Client profile="desktop" name="test1" pingable="N"
      uuid='9001ec29-1531-4b16-8198-a71bea093d0a' location='floating'/>
 
-Alternatively, the Client entry can be setup like:
+Alternatively, the Client entry can be setup like this:
 
 .. code-block:: xml
 
     <Client profile="desktop" name="test1" pingable="N"
      uuid='9001ec29-1531-4b16-8198-a71bea093d0a' address='ip-address-of-NAT'/>
 
-The difference between these definitions is explained in detail on the [wiki:Authentication] page, but in short, the second form requires that the client access the server from the NAT address, while the first form allows it to connect from any address provided it uses the proper uuid. (Client identification is orthogonal to the use of per-client passwords; this can be set in addition to the attributes above.)
+The difference between these definitions is explained in detail in the
+:ref:`appendix-guides-authentication` section, but in short, the second
+form requires that the client access the server from the NAT address,
+while the first form allows it to connect from any address provided it
+uses the proper uuid. (Client identification is orthogonal to the use
+of per-client passwords; this can be set in addition to the attributes
+above.)
 
-Once this setup is done, each client must be configured to use the proper uuid upon any server interaction. This can be done using either the command line argument -u, or the setting "user" in the "communication" section of /etc/bcfg2.conf.
+Once this setup is done, each client must be configured to use the proper
+uuid upon any server interaction. This can be done using either the
+command line argument -u, or the setting "user" in the "communication"
+section of ``/etc/bcfg2.conf``.
 
 UUID Choice
 ===========
 
-When determining client UUIDs, one must take care to ensure that UUIDs are unique to the client. Any hardware-specific attribute, like a hash of a mac address would be sufficient. Alternatively, if a local hostname is unique, it may be used as well.
+When determining client UUIDs, one must take care to ensure that UUIDs
+are unique to the client. Any hardware-specific attribute, like a hash
+of a mac address would be sufficient. Alternatively, if a local hostname
+is unique, it may be used as well.
 
 Automated Client Bootstrapping
 ==============================
 
-Automated setup of new clients from behind NAT works by using the common password. For example::
+Automated setup of new clients from behind NAT works by using the common
+password. For example::
 
     /usr/sbin/bcfg2 -u ubik3 -p desktop -x <password>
 
-It is not possible at this time to do automated setup without setting up a pre-shared per-client key.
+It is not possible at this time to do automated setup without setting
+up a pre-shared per-client key.
diff --git a/doc/appendix/guides/ubuntu.txt b/doc/appendix/guides/ubuntu.txt
index a4790ffed..595005018 100644
--- a/doc/appendix/guides/ubuntu.txt
+++ b/doc/appendix/guides/ubuntu.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _guide-ubuntu:
+.. _appendix-guides-ubuntu:
 
 ======
 Ubuntu
@@ -8,9 +8,9 @@ Ubuntu
 
 .. note::
 
-	    This particular how to was done on lucid, but should apply to any
-	    other `stable`__ version of Ubuntu.
-	
+    This particular how to was done on lucid, but should apply to any
+    other `stable`__ version of Ubuntu.
+
 __ ubuntu-releases_
 .. _ubuntu-releases: https://wiki.ubuntu.com/Releases
 
@@ -60,9 +60,9 @@ allows you to automate this process.::
     6: Gentoo
     7: FreeBSD
     : 5
-    Generating a 1024 bit RSA private key
-    .......................................................................................+++
-    ...++++++
+    Generating a 2048 bit RSA private key
+    ......................................................................................+++
+    ...+++
     writing new private key to '/etc/bcfg2.key'
     -----
     Signature ok
diff --git a/doc/appendix/guides/using-bcfg2-info.txt b/doc/appendix/guides/using-bcfg2-info.txt
index 5f77a3c70..b2354652f 100644
--- a/doc/appendix/guides/using-bcfg2-info.txt
+++ b/doc/appendix/guides/using-bcfg2-info.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _guide-using_bcfg2_info:
+.. _appendix-guides-using_bcfg2_info:
 
 ================
 Using bcfg2-info
diff --git a/doc/appendix/guides/using-bcfg2-with-centos.txt b/doc/appendix/guides/using-bcfg2-with-centos.txt
index 7c452f422..93875d4c5 100644
--- a/doc/appendix/guides/using-bcfg2-with-centos.txt
+++ b/doc/appendix/guides/using-bcfg2-with-centos.txt
@@ -43,9 +43,9 @@ Now you can install the rest of the prerequisites::
 Build Packages from source
 ##########################
 
-* After installing subversion, check out a copy of trunk ::
+* After installing git, clone the master branch::
 
-    [root@centos redhat]# svn co https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2
+    [root@centos redhat]# git clone git://git.mcs.anl.gov/bcfg2.git
 
 * Install the ``fedora-packager`` package ::
 
diff --git a/doc/appendix/guides/vcs.txt b/doc/appendix/guides/vcs.txt
index 207337c30..6c2879a65 100644
--- a/doc/appendix/guides/vcs.txt
+++ b/doc/appendix/guides/vcs.txt
@@ -1,28 +1,23 @@
 .. -*- mode: rst -*-
 
-.. _guide-vcs:
+.. _appendix-guides-vcs:
 
 =======================
 Version control systems
 =======================
 
-The sections in this guide do only cover the basics steps in the setup
-of the different version control system for the usage with the Bcfg2
-plugin support.  More more details about 
+The sections in this guide only cover the basics steps in the setup of
+the different version control systems for usage with the Bcfg2.
 
 Git
 ===
 
 .. _Git tutorial: http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
 
-Adding the :ref:`server-plugins-version-git` plugins can preserve
-versioning information. The first step is to add **Git** to your 
-plugin line::
-
-    plugins = Base,Bundler,Cfg,...,Git
-
-For tracking the configuration files in the ``/var/lib/bcfg2`` 
-directory a git repository need to be established::
+Adding the :ref:`server-plugins-version-git` plugin will allow you to
+store version information in the statistics database. For tracking the
+configuration files in the ``/var/lib/bcfg2`` directory a git repository
+needs to be established::
 
     git init
 
@@ -38,12 +33,11 @@ While running ``bcfg2-info`` the following line will show up::
 Mercurial 
 =========
 
-For the :ref:`server-plugins-version-hg` plugin are the same changes 
-needed as for git. ::
+The :ref:`server-plugins-version-hg` plugin also allows you to store
+version information in the statistics database.
 
-    plugins = Base,Bundler,Cfg,...,Mercurial
-
-The repository must be initialized::
+To use mercurial to track your configuration files, the repository must
+be initialized::
 
     hg init
 
@@ -68,12 +62,11 @@ While running ``bcfg2-info`` the following line will show up::
 Darcs 
 =====
 
-If you wish to use the :ref:`server-plugins-version-darcs` plugin an
-entry has to be made in the ``bcfg2.conf`` file.::
-
-    plugins = Base,Bundler,Cfg,...,Darcs
+The :ref:`server-plugins-version-darcs` plugin also allows you to store
+version information in the statistics database.
 
-The dracs repository must be initialized::
+To use darcs to track your configuration files, the repository must
+be initialized::
 
     darcs initialize
 
@@ -87,7 +80,8 @@ darcs will ask you to enter your e-mail address.
     you@example.com
     END_ENTRY
 
-All files in the ``/var/lib/bcfg2`` should be added to darcs now::
+All files in the ``/var/lib/bcfg2`` directory should be added to darcs
+now::
 
     darcs add *
 
@@ -102,8 +96,8 @@ While running ``bcfg2-info`` the following line will show up::
 Cvs
 ===
 
-If you wish to use the :ref:`server-plugins-version-darcs` plugin an
-entry has to be made in the ``bcfg2.conf`` file.::
+The :ref:`server-plugins-version-cvs` plugin also allows you to store
+version information in the statistics database.
 
     plugins = Base,Bundler,Cfg,...,Cvs
 
diff --git a/doc/appendix/guides/web-reports.txt b/doc/appendix/guides/web-reports-install.txt
index 9eadfb678..af2e240fa 100644
--- a/doc/appendix/guides/web-reports.txt
+++ b/doc/appendix/guides/web-reports-install.txt
@@ -5,7 +5,7 @@
 .. This is combination of the Ubuntu guide and the Centos guide for
    installing the web reports.
 
-.. _web-reports:
+.. _appendix-guides-web-reports-install:
 
 ==================================
 Dynamic (web) Reports installation
@@ -180,5 +180,5 @@ then have something like this::
 
 Restart apache and point a browser to your Bcfg2 server.
 
-If using sqlite be sure the sql database file and directory containing the
-database are writable to apache.
+If using sqlite be sure the sql database file and directory containing
+the database are writable to apache.
diff --git a/doc/appendix/index.txt b/doc/appendix/index.txt
index 1bac69a3d..407119e24 100644
--- a/doc/appendix/index.txt
+++ b/doc/appendix/index.txt
@@ -6,14 +6,6 @@
 Appendix
 ========
 
-Bcfg2 is based on a client-server architecture. The client is
-responsible for interpreting (but not processing) the configuration
-served by the server. This configuration is literal, so no local
-process is required. After completion of the configuration process,
-the client uploads a set of statistics to the server. This section
-will describe the goals and then the architecture motivated by it.
-
-
 .. toctree::
    :maxdepth: 2
 
diff --git a/doc/appendix/tools.txt b/doc/appendix/tools.txt
index 040823504..1d7a8dd90 100644
--- a/doc/appendix/tools.txt
+++ b/doc/appendix/tools.txt
@@ -11,4 +11,4 @@ can help you to maintain your Bcfg2 configuration, to make the initial
 setup easier, or to do some other tasks. 
 
 
-http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/tools
+http://trac.mcs.anl.gov/projects/bcfg2/browser/tools