Upstart: Add new upstart client tool

Due to the nature of the way Upstart handles service specification,
turning 'servicename' off and on can be done via a configuration file
located at /etc/init/<servicename>.conf. Enabling a disabled service can
be done by making sure that the Upstart configuration file and the
service are bundled together.

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

2 files changed, 32 insertions, 27 deletions

diff --git a/doc/getting_started/index.txt b/doc/getting_started/index.txt
index 01c264233..c3e27000b 100644
--- a/doc/getting_started/index.txt
+++ b/doc/getting_started/index.txt
@@ -18,6 +18,11 @@ Channel` and let us know)
 
 * `Bcfg2 from scratch on CentOS <QuickStart/CentOS>`
 
+.. toctree::
+   :maxdepth: 2
+
+   using-bcfg2-info
+
 Must Reads
 ==========
 
diff --git a/doc/getting_started/using-bcfg2-info.txt b/doc/getting_started/using-bcfg2-info.txt
index 0aee53caf..dc5e3ea10 100644
--- a/doc/getting_started/using-bcfg2-info.txt
+++ b/doc/getting_started/using-bcfg2-info.txt
@@ -1,9 +1,9 @@
 .. -*- mode: rst -*-
 
-.. _using_bcfg2_info:
+.. _getting_started-using_bcfg2_info:
 
 ================
-Using bcfg2-info 
+Using bcfg2-info
 ================
 
 *bcfg2-info* is a tool for introspecting server functions. It is
@@ -14,29 +14,29 @@ without all of the network communication code. Think of *bcfg2-info*
 as *bcfg2-server* on a stick. It is a useful location to do testing
 and staging of new configuration rules, prior to deployment. This is
 particularly useful when developing templates, or developing Bcfg2
-plugins. 
+plugins.
 
 Getting Started
 ===============
 
-First, fire up the bcfg2-info interpreter. 
+First, fire up the bcfg2-info interpreter.
 
 .. code-block:: none
 
-     [0:464] bcfg2-info 
-     Loading experimental plugin(s): Packages 
-     NOTE: Interfaces subject to change 
-     Handled 8 events in 0.006s 
-     Handled 4 events in 0.035s 
-     Welcome to bcfg2-info 
-     Type "help" for more information 
-     > 
+     [0:464] bcfg2-info
+     Loading experimental plugin(s): Packages
+     NOTE: Interfaces subject to change
+     Handled 8 events in 0.006s
+     Handled 4 events in 0.035s
+     Welcome to bcfg2-info
+     Type "help" for more information
+     >
 
 At this point, the server core has been loaded up, all plugins have
 been loaded, and the *bcfg2-info* has both read the initial state of
 the Bcfg2 repository, as well as begun monitoring it for changes. Like
 *bcfg2-server*, *bcfg2-info* monitors the repository for changes,
-however, unlink *bcfg2-server*, it does not process change events
+however, unlike *bcfg2-server*, it does not process change events
 automatically. File modification events can be processed by explicitly
 calling the **update** command. This will process the events,
 displaying the number of events processed and the amount of time taken
@@ -52,22 +52,22 @@ displayed. For example, after a change to a file in the repository:
 
 This explicit update process allows you to control the update process,
 as well as see the precise changes caused by repository
-modifications. 
+modifications.
 
 *bcfg2-info* has several builtin commands that display the state of
 various internal server core state. These are most useful for
 examining the state of client metadata, either for a single client, or
-for clients overall. 
+for clients overall.
 
-**clients** 
+**clients**
      displays a list of clients, along with their profile groups
-**groups** 
+**groups**
      displays a list of groups, the inheritance hierarchy, profile
-     status, and category name, if there is one. 
+     status, and category name, if there is one.
 **showclient**
      displays full metadata information for a client, including
      profile group, group memberships, bundle list, and any connector
-     data, like Probe values or Property info. 
+     data, like Probe values or Property info.
 
 Debugging Configuration Rules
 =============================
@@ -83,7 +83,7 @@ three major steps:
 
 Step *1* can be viewed with the commands presented in the previous
 section. The latter two steps can be examined using the following
-commands. 
+commands.
 
 **showentries**
      displays a list of entries (optionally filtered by type) that
@@ -92,16 +92,16 @@ commands.
 **buildfile**
      Perform the entry binding process on a single entry, displaying
      its results. This command is very useful when developing
-     configuration file templates. 
+     configuration file templates.
 
 **build**
      Build the full configuration specification and write it to a
-     file. 
+     file.
 
 **mappings**
      displays the entries handled by the plugins loaded by the server
      core. This command is useful when the server reports a bind
-     failure for an entry. 
+     failure for an entry.
 
 Debugging and Developing Bcfg2
 ==============================
@@ -109,12 +109,12 @@ Debugging and Developing Bcfg2
 *bcfg2-info* loads a full Bcfg2 server core, so it provides the ideal
 environment for developing and debugging Bcfg2. Because it is hard to
 automate this sort of process, we have only implemented two commands
-in *bcfg2-info* to aid in the process. 
+in *bcfg2-info* to aid in the process.
 
 **profile**
      The profile command produces python profiling information for
      other *bcfg2-info* commands. This can be used to track
-     performance problems in configuration generation. 
+     performance problems in configuration generation.
 
 **debug**
      The debug command exits the *bcfg2-info* interpreter loop and
@@ -122,8 +122,8 @@ in *bcfg2-info* to aid in the process.
      available in this namespace as "self". Full documentation for
      the server core is out of scope for this document. This
      capability is most useful to call into plugin methods, often with
-     setup calls or the enabling of diagnostics. 
+     setup calls or the enabling of diagnostics.
 
      It is possible to return to the *bcfg2-info* command loop by
-     exiting the python interpreter with ^D. 
+     exiting the python interpreter with ^D.