doc: Style consistency updates

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

22 files changed, 97 insertions, 95 deletions

diff --git a/doc/client/agent.txt b/doc/client/agent.txt
index eec66964f..ef152133e 100644
--- a/doc/client/agent.txt
+++ b/doc/client/agent.txt
@@ -8,11 +8,11 @@ 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
+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
+#. 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.::
@@ -29,8 +29,8 @@ is pretty easy:
 
        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
+   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.
@@ -41,7 +41,7 @@ is pretty easy:
 
    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
+   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
diff --git a/doc/client/index.txt b/doc/client/index.txt
index 536bedfbb..5e6551387 100644
--- a/doc/client/index.txt
+++ b/doc/client/index.txt
@@ -5,10 +5,11 @@
 The Bcfg2 Client
 ================
 
-The Bcfg2 client is responsible for determining what reconfiguration
-operations must be undertaken on the client, but does not perform
-any processing of the target configuration description. We chose this
-architecture, as opposed to one with a smarter client, for a few reasons:
+The Bcfg2 client attempts to reconcile the current configuration state
+with the configuration passed down from the server using various client
+tools. It does not perform any processing of the target configuration
+description. We chose this architecture, as opposed to one with a smarter
+client, for a few reasons:
 
 * Client failure forces administrators to perform an O(n) reconfiguration
   operation. Simpler code is easier to debug and maintain.
@@ -22,16 +23,22 @@ architecture, as opposed to one with a smarter client, for a few reasons:
   deployment engine that can be driven by anything that writes a
   compatible configuration description.
 
+Available client tools
+----------------------
+
 .. toctree::
    :maxdepth: 2
+   :glob:
 
-   agent
-   debugging
-   metadata
-   modes
+   tools/*
+
+Other client-related documentation
+----------------------------------
 
 .. toctree::
    :maxdepth: 2
-   :glob:
 
-   tools/*
+   agent
+   debugging
+   metadata
+   modes
diff --git a/doc/client/modes.txt b/doc/client/modes.txt
index f3f48ca38..55aec34e7 100644
--- a/doc/client/modes.txt
+++ b/doc/client/modes.txt
@@ -33,7 +33,7 @@ How do I use it?
 #. 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).
+   path in the [paranoid] section of ``/etc/bcfg2``).
 #. On the client, run `bcfg2` with the `-P` option (alternatively, you
    can set *paranoid* to *true* in the **[client]** section of
    ``bcfg2.conf``).
@@ -47,7 +47,7 @@ Extra configuration
 -------------------
 
 Here is an example of how to use the extra paranoid features available
-in 1.0. For the following section in bcfg2.conf::
+in 1.0. For the following section in ``bcfg2.conf``::
 
     [paranoid]
     path = /my/custom/backup/path
diff --git a/doc/client/tools/apt.txt b/doc/client/tools/apt.txt
index dba359e4a..8ce997007 100644
--- a/doc/client/tools/apt.txt
+++ b/doc/client/tools/apt.txt
@@ -2,9 +2,9 @@
 
 .. _client-tools-apt:
 
-=====================
-Bcfg2 APT Client Tool
-=====================
+===============
+APT Client Tool
+===============
 
 The APT tool allows you to configure custom options in ``bcfg2.conf``
 for systems where the tools reside in non-standard locations. The
diff --git a/doc/client/tools/index.txt b/doc/client/tools/index.txt
index a613b9d40..878a221ee 100644
--- a/doc/client/tools/index.txt
+++ b/doc/client/tools/index.txt
@@ -5,7 +5,7 @@
 Client Tool Drivers
 ===================
 
-Client tool drivers allow bcfg2 to execute configuration operations by
+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
@@ -16,21 +16,21 @@ operations.
 To write your own tool driver, to handle a new packaging format, or new
 service architecture see :ref:`development-index-writingtooldrivers`
 
-When the bcfg2 client is run, it attempts to instantiate each of these
+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
+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:
+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
+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.
 
diff --git a/doc/client/tools/yumng.txt b/doc/client/tools/yumng.txt
index 07706ad8b..c3b645a4f 100644
--- a/doc/client/tools/yumng.txt
+++ b/doc/client/tools/yumng.txt
@@ -74,7 +74,7 @@ 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
+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.
 
@@ -150,7 +150,7 @@ From the command line::
 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::
+In the ``bcfg2.conf`` file::
 
     [client]
     #drivers = Action,Chkconfig,POSIX,YUMng
@@ -411,7 +411,7 @@ 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
+gpg-pubkey packages will be removed by ``bcfg2 -r packages`` if they are
 not in the clients configuration.
 
 .. code-block:: xml
@@ -752,7 +752,7 @@ For RPMng a minimal entry is
 verify_fail_action
 ^^^^^^^^^^^^^^^^^^
 
-The way I have bcfg2 configured for my development systems. This way
+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/index.txt b/doc/index.txt
index c9252a379..894996ffe 100644
--- a/doc/index.txt
+++ b/doc/index.txt
@@ -40,33 +40,33 @@ deployment strategies.
 Architecture
 ------------
 
-Bcfg2 provides a declarative interface to system configuration. It was
-designed and implemented in-house at Argonne National Laboratory, but
-has matured to the point that external sites have begun using it. Its
-configuration specifications describe a literal configuration goal state
-for clients. In this architecture, the Bcfg2 client tool is responsible
-for determining what, if any, configuration operations must occur and
-then performing those operations. The client also uploads statistics and
-client configuration state information. The design and implementation
-of the reporting system is described in a separate
+Bcfg2 provides a declarative interface to system configuration. Its
+configuration specifications describe a literal configuration goal
+state for clients. In this architecture, the Bcfg2 client tool is
+responsible for determining what, if any, configuration operations must
+occur and then performing those operations. The client also uploads
+statistics and client configuration state information. The design
+and implementation of the reporting system is described on a separate
 :ref:`page <server-reports-index>`.
 
 A comprehensive description of the Bcfg2 Architecture (and the choices
-behind the design) can be found at :ref:`architecture`
+behind the design) can be found at :ref:`architecture`.
 
 Server
 ^^^^^^
 
-The role of the bcfg2 server is rendering a client-specific target
+The role of the Bcfg2 server is rendering a client-specific target
 configuration description from a global specification. The specification
 consists of a directory structure containing data for a variety of server
-plugins. The bcfg2 server has a plugin interface that can be used to
-interpret parts configuration specification.
+plugins. The Bcfg2 server has a plugin interface that can be used to
+interpret the configuration specification.
 
 Client
 ^^^^^^
 
-Read on for more information about :ref:`client-index`.
+The Bcfg2 client is responsible for determining what operations are
+necessary in order to reach the desired configuration state.  Read on
+for more information about :ref:`client-index`.
 
 What Operating Systems Does Bcfg2 Support?
 ==========================================
diff --git a/doc/server/configurationentries.txt b/doc/server/configurationentries.txt
index b07f8de2a..393984771 100644
--- a/doc/server/configurationentries.txt
+++ b/doc/server/configurationentries.txt
@@ -48,7 +48,7 @@ a device, directory, hardlink, symlink, etc), then you will specify both
 the *type* and any other necessary attributes in `Rules`_.
 
 .. note:: A tool for converting old POSIX entries is available in the
-          bcfg2 source directory at tools/posixunified.py
+          Bcfg2 source directory at tools/posixunified.py
 
 +-------------+----------------------+-----------------+--------------------------+
 | Type        | Replacement/New      | Description     | Attributes               |
diff --git a/doc/server/plugins/generators/decisions.txt b/doc/server/plugins/generators/decisions.txt
index 52e5c316e..5c7332dfb 100644
--- a/doc/server/plugins/generators/decisions.txt
+++ b/doc/server/plugins/generators/decisions.txt
@@ -22,7 +22,7 @@ should be corrected during the current run of the installation tool. The
 Decision plugin is the only stock plugin that generates entries for
 client's whitelists or blacklists.
 
-The Decision plugin uses a directory in the bcfg2 repository called
+The Decision plugin uses a directory in the Bcfg2 repository called
 Decisions. Files in the Decisions subdirectory are named similarly to
 files managed by Cfg, probes, TCheetah, and TGenshi. File basenames
 are either whitelist or blacklist. These files have a simple format;
diff --git a/doc/server/plugins/generators/hostbase.txt b/doc/server/plugins/generators/hostbase.txt
index bf28e401d..c6007f70e 100644
--- a/doc/server/plugins/generators/hostbase.txt
+++ b/doc/server/plugins/generators/hostbase.txt
@@ -138,11 +138,11 @@ 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
+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
+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.
@@ -190,7 +190,7 @@ 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
+Add ``'Hostbase.rebuildState'`` to the list of methods in the Bcfg2
 client proxy object.  The modified list is shown below:
 
 .. code-block:: python
@@ -200,9 +200,9 @@ client proxy object.  The modified list is shown below:
         name = 'bcfg2'
         methods = ['AssertProfile', 'GetConfig', 'GetProbes', 'RecvProbeData', 'RecvStats', 'Hostbase.rebuildState']
 
-Now copy the file ``hostbasepush.py`` from ``bcfg2/tools`` in the bcfg2
+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
+the Hostbase to rebuild it's files, then runs the Bcfg2 client on your
 local machine to grab the new configs.
 
 NIS Authentication
diff --git a/doc/server/plugins/generators/nagiosgen.txt b/doc/server/plugins/generators/nagiosgen.txt
index f6362dbdd..64b9c02fa 100644
--- a/doc/server/plugins/generators/nagiosgen.txt
+++ b/doc/server/plugins/generators/nagiosgen.txt
@@ -120,7 +120,7 @@ add services, and commands specific to the hostgroup (Bcfg2 group) in
             hostgroup_name                  web-server
             }
 
-Create a nagios bcfg2 bundle /var/lib/bcfg2/Bundler/nagios.xml
+Create a nagios Bcfg2 bundle ``/var/lib/bcfg2/Bundler/nagios.xml``
 
 .. code-block:: xml
 
@@ -166,6 +166,6 @@ Update nagios configuration file to use nagiosgen.cfg::
     cfg_file=/etc/nagios/nagiosgen.cfg
 
 Note that some of these files are built on demand, each time a client
-in group "nagios-server" checks in with the bcfg2 server. Local nagios
-instances can be configured to use the !NagiosGen directory in the bcfg2
+in group "nagios-server" checks in with the Bcfg2 server. Local nagios
+instances can be configured to use the !NagiosGen directory in the Bcfg2
 repository directly.
diff --git a/doc/server/plugins/generators/sshbase.txt b/doc/server/plugins/generators/sshbase.txt
index ec378956d..6abb05ed9 100644
--- a/doc/server/plugins/generators/sshbase.txt
+++ b/doc/server/plugins/generators/sshbase.txt
@@ -6,7 +6,7 @@
 SSHbase
 =======
 
-SSHbase is a purpose build bcfg2 plugin for managing ssh host keys. It
+SSHbase is a purpose build Bcfg2 plugin for managing ssh host keys. It
 is responsible for making ssh keys persist beyond a client rebuild and
 building a proper ssh_known_hosts file, including a correct localhost
 record for the current system.
@@ -47,7 +47,7 @@ Getting started
 ===============
 
 #. Add SSHbase to the **plugins** line in ``/etc/bcfg2.conf`` and
-   restart the server -- This enables the SSHbase plugin in the bcfg2
+   restart the server -- This enables the SSHbase plugin on the Bcfg2
    server.
 
 #. Add Path entries for ``/etc/ssh/ssh_known_hosts``, and
diff --git a/doc/server/plugins/index.txt b/doc/server/plugins/index.txt
index 8035f3c31..126331325 100644
--- a/doc/server/plugins/index.txt
+++ b/doc/server/plugins/index.txt
@@ -18,8 +18,8 @@ perform one of several tasks:
 Enabling Plugins
 ================
 
-In order for the bcfg2 server to use a plugin, it needs to be listed on
-the *plugins* line in bcfg2.conf.
+In order for the Bcfg2 server to use a plugin, it needs to be listed on
+the *plugins* line in ``bcfg2.conf``.
 
 Default Plugins
 ===============
diff --git a/doc/server/reports/dynamic.txt b/doc/server/reports/dynamic.txt
index 88319d263..6345e724d 100644
--- a/doc/server/reports/dynamic.txt
+++ b/doc/server/reports/dynamic.txt
@@ -20,7 +20,7 @@ Prerequisites
 Install
 -------
 
-Be sure to include the specified fields included the example bcfg2.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``.
 
@@ -32,9 +32,9 @@ If you are not using sqlite (the default choice), please see the
 :ref:`alternative-databases` section below.
 
 The recommended statistics plugin is DBStats. To use it, add it to the
-``plugins`` line in your bcfg2.conf.
+**plugins** line in your ``bcfg2.conf``.
 
-Restart the bcfg2 server. Run a client in dryrun mode in order to get
+Restart the Bcfg2 server. Run a client in dryrun mode in order to get
 the client's statistics loaded into the database.
 
 .. _dynamic-http-install:
@@ -124,13 +124,8 @@ Apache conf::
 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
+``/etc/bcfg2.conf``.
 
 Summary and Features
 ====================
diff --git a/doc/server/reports/static.txt b/doc/server/reports/static.txt
index 0767a6b2d..d5d96fe12 100644
--- a/doc/server/reports/static.txt
+++ b/doc/server/reports/static.txt
@@ -43,11 +43,11 @@ record most of the data that users would like.
 Setup
 =====
 
-In order to configure your bcfg2 server for receiving reports, you
+In order to configure your Bcfg2 server for receiving reports, you
 will need to list the Statistics plugin in the plugins line of your
-bcfg2.conf (starting in 1.0). You will also need a [statistics] section
-in your bcfg2.conf. You can find out more about what goes there in the
-bcfg2.conf manpage.
+``bcfg2.conf``. You will also need a [statistics] section
+in your ``bcfg2.conf``. You can find out more about what goes there in the
+``bcfg2.conf`` manpage.
 
 Output
 ======
diff --git a/doc/unsorted/development_writing_plugins.txt b/doc/unsorted/development_writing_plugins.txt
index 89b1af28a..cc0bd7c00 100644
--- a/doc/unsorted/development_writing_plugins.txt
+++ b/doc/unsorted/development_writing_plugins.txt
@@ -66,7 +66,7 @@ If you would like to define your own Metadata plugin (to extend/change functiona
        import Bcfg2.Server.Plugins.Metadata
 
        class MyMetadata(Bcfg2.Server.Plugins.Metadata.Metadata):
-           '''This class contains data for bcfg2 server metadata'''
+           '''This class contains data for Bcfg2 server metadata'''
            __version__ = '$Id$'
            __author__ = 'bcfg-dev@mcs.anl.gov'
 
diff --git a/doc/unsorted/dynamic_groups.txt b/doc/unsorted/dynamic_groups.txt
index e8d2de396..11535dc8b 100644
--- a/doc/unsorted/dynamic_groups.txt
+++ b/doc/unsorted/dynamic_groups.txt
@@ -21,7 +21,7 @@ based on system properties::
 
     group:groupname
 
-This output is processed by the bcfg2 server, and results in dynamic
+This output is processed by the Bcfg2 server, and results in dynamic
 group membership in groupname for the client. See the :ref:`Probes
 <server-plugins-probes-index>` page for a more thorough description
 of probes.
diff --git a/doc/unsorted/gentoo.txt b/doc/unsorted/gentoo.txt
index 015a19687..4a549210d 100644
--- a/doc/unsorted/gentoo.txt
+++ b/doc/unsorted/gentoo.txt
@@ -7,23 +7,23 @@ Gentoo
 ======
 
 This document tries to lay out anything Gentoo-specific that you need
-to know in order to use bcfg2. Mostly that has to do with getting it
+to know in order to use Bcfg2. Mostly that has to do with getting it
 to cooperate with the various pieces of Portage. Services, all things
-POSIX, and just about anything else that bcfg2 does will work the same
-on Gentoo as on any other distribution.  bcfg2 is new on Gentoo; please
+POSIX, and just about anything else that Bcfg2 does will work the same
+on Gentoo as on any other distribution.  Bcfg2 is new on Gentoo; please
 let the list know if you find errors or omissions.
 
-Installing bcfg2
+Installing Bcfg2
 ================
 
-Early in July 2008, bcfg2 was added to the Gentoo portage tree.  So far
+Early in July 2008, Bcfg2 was added to the Gentoo portage tree.  So far
 it's only keyworded for ~x86, but we hope to see it soon in the amd64 and
 x64-solaris ports.  If you're using Gentoo on some other architecture, it
 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
+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``
@@ -106,7 +106,7 @@ conjunction with the `quickpkg` example above:
 Configuring Client Machines
 ===========================
 
-Set up ``/etc/bcfg2.conf`` the way you would for any other bcfg2 client.
+Set up ``/etc/bcfg2.conf`` the way you would for any other Bcfg2 client.
 
 In ``make.conf``, set *PORTAGE_BINHOST* to point to the URI of
 your package repository.  You may want to create versions of
@@ -127,7 +127,7 @@ 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
-nonetheless recorded in the package database; in some (python, bcfg2,
+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
@@ -145,12 +145,12 @@ leading to noise like this::
      * 62 out of 66 files good
 
 We can ignore the lines for ``ssh_config`` and ``sshd_config``; those will
-be caught by bcfg2 as registered config files and handled appropriately.
+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
+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.
@@ -170,7 +170,7 @@ Gentoo as well as some other distros recommend leaving ``/boot`` unmounted
 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
+``/boot`` is mounted whenever you run Bcfg2, possibly wrapping Bcfg2
 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
diff --git a/doc/unsorted/howtos.txt b/doc/unsorted/howtos.txt
index bc9c75970..b81f17130 100644
--- a/doc/unsorted/howtos.txt
+++ b/doc/unsorted/howtos.txt
@@ -8,11 +8,11 @@ HOWTOs
 
 Here are several howtos that describe different aspects of Bcfg2 deployment
 
-* [wiki:Authentication] - a description of the bcfg2 authentication infrastructure
-* AnnotatedExamples - a description of basic bcfg2 specification operations
+* [wiki:Authentication] - a description of the Bcfg2 authentication infrastructure
+* AnnotatedExamples - a description of basic Bcfg2 specification operations
 * EncapPackages, EncapReadme, EncapInstall, EncapHowto - building encap packages
 * BuildingDebianPackages - How to build debian packages
-* [wiki:Gentoo] - Issues specific to running bcfg2 on Gentoo
+* [wiki:Gentoo] - Issues specific to running Bcfg2 on Gentoo
 * [wiki:Plugins/TCheetah TCheetah] - Howto use the TCheetah template plugin
 * [wiki:Hostbase] - How to use the Hostbase plugin and web interface
 * [wiki:Plugins/Probes Probes] - How to use Probes to gather information from a client machine.
diff --git a/doc/unsorted/mailinglist.txt b/doc/unsorted/mailinglist.txt
index 8f49b2706..72b971d77 100644
--- a/doc/unsorted/mailinglist.txt
+++ b/doc/unsorted/mailinglist.txt
@@ -6,7 +6,7 @@
 Mailing List
 ============
 
-To subscribe to the mailing list for bcfg2 please visit the `bcfg-dev
+To subscribe to the mailing list for Bcfg2 please visit the `bcfg-dev
 mailman page`_
 
 `Searchable archives`_ are available from Gmane. You can also read the
diff --git a/doc/unsorted/ssl.txt b/doc/unsorted/ssl.txt
index 919f7ea71..91b62ca59 100644
--- a/doc/unsorted/ssl.txt
+++ b/doc/unsorted/ssl.txt
@@ -14,7 +14,7 @@ required. A central CA needs to be created, with each server and all
 clients getting a signed cert. See [wiki:Authentication] for details.
 
 Setting up keys is accomplished with three settings, each in the
-"`[communication]`" section of bcfg2.conf::
+"`[communication]`" section of ``bcfg2.conf``::
 
     key = /path/to/ssl private key
     certificate = /path/to/signed cert for that key
@@ -27,7 +27,7 @@ Python SSL Backport Packaging
 Both the Bcfg2 server and client are able to use the in-tree ssl module
 included with python 2.6. The client is also able to still use M2Crypto. A
 python ssl backport exists for 2.3, 2.4, and 2.5. With this, M2Crypto
-is not needed, and tlslite is no longer included with bcfg2 sources. See
+is not needed, and tlslite is no longer included with Bcfg2 sources. See
 [wiki:Authentication] for details.
 
 To build a package of the ssl backport for .deb based distributions
@@ -54,7 +54,7 @@ can be found in the `python-setuptools` package.::
 
 .. note:: Version numbers for the SSL module have changed.
 
-For complete bcfg2 goodness, you'll also want to package stdeb using stdeb.
+For complete Bcfg2 goodness, you'll also want to package stdeb using stdeb.
 The completed debian package can be grabbed from :download:`here
 <python-stdeb_0.3-1_all.deb>`, which was generated using the following::
 
diff --git a/doc/unsorted/writing_specification.txt b/doc/unsorted/writing_specification.txt
index ce7630fde..02f66255b 100644
--- a/doc/unsorted/writing_specification.txt
+++ b/doc/unsorted/writing_specification.txt
@@ -160,7 +160,7 @@ apply to clients who are not a member of said group.
 
 When packages in a bundle are verified by the client toolset, the Paths
 included in the same bundle are taken into consideration.  That is,
-a package will not fail verification from a bcfg2 perspective if the
+a package will not fail verification from a Bcfg2 perspective if the
 package verification only failed because of configuration files that
 are defined in the same bundle.
 
@@ -314,7 +314,7 @@ other groups.
 Literal Configuration (Generators)
 ==================================
 
-A Generator is a bcfg2 piece of code that is run to generate the literal
+A Generator is a Bcfg2 piece of code that is run to generate the literal
 configuration for a host using a combination of the hosts metadata and
 abstract configuration.