36 files changed, 548 insertions, 66 deletions

diff --git a/doc/client/tools/yumng.txt b/doc/client/tools/yumng.txt
index 8f8575d18..cb749ba7f 100644
--- a/doc/client/tools/yumng.txt
+++ b/doc/client/tools/yumng.txt
@@ -19,7 +19,11 @@ Examples of this are:
 * YUM always installs, as opposed to upgrades, kernel packages.  This is hard coded in YUM (actually it can be overridden in yum.conf), so systems using YUM will eventually have multiple kernel packages installed.
 * Red Hat family x86_64 based systems frequently have both an x86_64 and an i386 version of the same package installed.
 
-The new Pkgmgr format files with Instances are therefore the only way to accurately describe an RPM based system.  It is recommended that all RPM based systems be changed to use the new format configuration files and the RPMng driver. Alternatively, you can use the newer :ref:`Packages <plugins-generators-packages>` plugin.
+The new Pkgmgr format files with Instances are therefore the only way to
+accurately describe an RPM based system.  It is recommended that all RPM
+based systems be changed to use the new format configuration files and
+the RPMng driver. Alternatively, you can use the newer :ref:`Packages
+<server-plugins-generators-packages>` plugin.
 
 Development Status
 ==================
@@ -357,7 +361,7 @@ Example gpg-pubkey Pkgmgr configuration file.
 Pkgmgr Configuration
 --------------------
 
-Also see the general :ref:`Pkgmgr <plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages.
+Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages.
  
 Package Tag (Old style)
 ^^^^^^^^^^^^^^^^^^^^^^^
@@ -456,7 +460,7 @@ Automated Generation of Pkgmgr Configuration Files
 
 The two utilities detailed below are provided in the tools directory of the source tarball.
 
-Also see the general :ref:`Pkgmgr <plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages.
+Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>` and [wiki:altsrc altsrc] pages.
 
 pkgmgr_gen.py
 ^^^^^^^^^^^^^
diff --git a/doc/contents.txt b/doc/contents.txt
index 615a7f010..dd1c98423 100644
--- a/doc/contents.txt
+++ b/doc/contents.txt
@@ -14,7 +14,7 @@ Welcome to Bcfg2's documentation!
    faq/index
    authentication
    getting_started/index
-   plugins/index
+   server/index
    client/index
    gettinghelp
 
diff --git a/doc/plugins/structures/base.txt b/doc/plugins/structures/base.txt
deleted file mode 100644
index eebeadd48..000000000
--- a/doc/plugins/structures/base.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _plugins-structures-base:
-
-====
-Base
-====
-
-The Base plugin is a structure plugin that provides the ability to add lists of unrelated entries into client configuration entry inventories. Base works much like Bundler in its file format. The main difference between Base and Bundler is that Base files are included in all clients' configuration whereas bundles must be included explicitly in your Metadata. See the :ref:`plugins-structures-bundler` page for details.
diff --git a/doc/quickstart/index.txt b/doc/quickstart/index.txt
index 11bb03083..7fcbc5e02 100644
--- a/doc/quickstart/index.txt
+++ b/doc/quickstart/index.txt
@@ -229,7 +229,7 @@ you will find that we now have a correct entry::
 
 Done! Now we just have 242 (or more) entries to take care of!
 
-:ref:`plugins-structures-bundler` is a relatively easy directory to
+:ref:`server-plugins-structures-bundler` is a relatively easy directory to
 populate. You can find many samples of Bundles in the `Bundle
 Repository`_, many of which can be used without editing.
 
diff --git a/doc/server/index.txt b/doc/server/index.txt
new file mode 100644
index 000000000..6e7f82693
--- /dev/null
+++ b/doc/server/index.txt
@@ -0,0 +1,13 @@
+.. -*- mode: rst -*-
+
+.. _server-index:
+
+============
+Bcfg2 Server
+============
+
+.. toctree::
+   :maxdepth: 2
+
+   plugins/index
+   reports/index
diff --git a/doc/plugins/generators/account.txt b/doc/server/plugins/generators/account.txt
index 9a37b2c69..93b3b8b88 100644
--- a/doc/plugins/generators/account.txt
+++ b/doc/server/plugins/generators/account.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-account:
+.. _server-plugins-generators-account:
 
 =======
 Account
diff --git a/doc/plugins/generators/cfg.txt b/doc/server/plugins/generators/cfg.txt
index 3870e8386..28752187d 100644
--- a/doc/plugins/generators/cfg.txt
+++ b/doc/server/plugins/generators/cfg.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-cfg:
+.. _server-plugins-generators-cfg:
 
 ===
 Cfg
diff --git a/doc/plugins/generators/decisions.txt b/doc/server/plugins/generators/decisions.txt
index 67860b86c..9d33a9b31 100644
--- a/doc/plugins/generators/decisions.txt
+++ b/doc/server/plugins/generators/decisions.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-decisions:
+.. _server-plugins-generators-decisions:
 
 =========
 Decisions
diff --git a/doc/plugins/generators/deps.txt b/doc/server/plugins/generators/deps.txt
index 890fe0c39..9f704e905 100644
--- a/doc/plugins/generators/deps.txt
+++ b/doc/server/plugins/generators/deps.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-deps:
+.. _server-plugins-generators-deps:
 
 ====
 Deps
diff --git a/doc/plugins/generators/hostbase.txt b/doc/server/plugins/generators/hostbase.txt
index 18bda9964..4cabf468a 100644
--- a/doc/plugins/generators/hostbase.txt
+++ b/doc/server/plugins/generators/hostbase.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-hostbase:
+.. _server-plugins-generators-hostbase:
 
 ========
 Hostbase
diff --git a/doc/plugins/generators/nagiosgen.txt b/doc/server/plugins/generators/nagiosgen.txt
index 026109f21..23aeebd05 100644
--- a/doc/plugins/generators/nagiosgen.txt
+++ b/doc/server/plugins/generators/nagiosgen.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-nagiosgen:
+.. _server-plugins-generators-nagiosgen:
 
 =========
 NagiosGen
diff --git a/doc/plugins/generators/packages.txt b/doc/server/plugins/generators/packages.txt
index 5efe5706d..b12e15984 100644
--- a/doc/plugins/generators/packages.txt
+++ b/doc/server/plugins/generators/packages.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-packages:
+.. _server-plugins-generators-packages:
 
 ========
 Packages
diff --git a/doc/plugins/generators/pkgmgr.txt b/doc/server/plugins/generators/pkgmgr.txt
index 89e67e5b7..81ff6b8a3 100644
--- a/doc/plugins/generators/pkgmgr.txt
+++ b/doc/server/plugins/generators/pkgmgr.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-pkgmgr:
+.. _server-plugins-generators-pkgmgr:
 
 ======
 Pkgmgr
diff --git a/doc/plugins/generators/rules.txt b/doc/server/plugins/generators/rules.txt
index d05fef773..34be180bf 100644
--- a/doc/plugins/generators/rules.txt
+++ b/doc/server/plugins/generators/rules.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-rules:
+.. _server-plugins-generators-rules:
 
 =====
 Rules
diff --git a/doc/plugins/generators/sshbase.txt b/doc/server/plugins/generators/sshbase.txt
index 7ce066cc7..21d4117fa 100644
--- a/doc/plugins/generators/sshbase.txt
+++ b/doc/server/plugins/generators/sshbase.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-sshbase:
+.. _server-plugins-generators-sshbase:
 
 =======
 SSHbase
diff --git a/doc/plugins/generators/tcheetah.txt b/doc/server/plugins/generators/tcheetah.txt
index 829e25901..a338b0cb3 100644
--- a/doc/plugins/generators/tcheetah.txt
+++ b/doc/server/plugins/generators/tcheetah.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-tcheetah:
+.. _server-plugins-generators-tcheetah:
 
 ========
 TCheetah
diff --git a/doc/plugins/generators/tgenshi.txt b/doc/server/plugins/generators/tgenshi.txt
index bc0de8cbc..c0d9427b1 100644
--- a/doc/plugins/generators/tgenshi.txt
+++ b/doc/server/plugins/generators/tgenshi.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-generators-tgenshi:
+.. _server-plugins-generators-tgenshi:
 
 =======
 TGenshi
diff --git a/doc/plugins/grouping/bb.txt b/doc/server/plugins/grouping/bb.txt
index 3c0846975..7acf132c2 100644
--- a/doc/plugins/grouping/bb.txt
+++ b/doc/server/plugins/grouping/bb.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-grouping-bb:
+.. _server-plugins-grouping-bb:
 
 ==
 BB
diff --git a/doc/plugins/grouping/metadata.txt b/doc/server/plugins/grouping/metadata.txt
index 14ada3f7a..085d09717 100644
--- a/doc/plugins/grouping/metadata.txt
+++ b/doc/server/plugins/grouping/metadata.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-grouping-metadata:
+.. _server-plugins-grouping-metadata:
 
 ========
 Metadata
@@ -217,4 +217,4 @@ Probes
 ======
 
 The metadata plugin includes client-side probing functionality. This
-is fully documented :ref:`here <plugins-probes>`.
+is fully documented :ref:`here <server-plugins-probes>`.
diff --git a/doc/plugins/index.txt b/doc/server/plugins/index.txt
index f0c82c030..5fcdc281b 100644
--- a/doc/plugins/index.txt
+++ b/doc/server/plugins/index.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-index:
+.. _server-plugins-index:
 
 =======
 Plugins
@@ -10,8 +10,8 @@ Plugins are the source of all logic used in building a config. They can perform
 
 #. Generating configuration inventory lists for clients
 #. Generating configuration entry contents for clients
-#. Probing client-side state (like hardware inventory, etc) -- the generic client probing mechanism is described at :ref:`plugins-probes`.
-#. Automating administrative tasks (e.g. :ref:`plugins-generators-sshbase` which automates ssh key management)
+#. Probing client-side state (like hardware inventory, etc) -- the generic client probing mechanism is described at :ref:`server-plugins-probes`.
+#. Automating administrative tasks (e.g. :ref:`server-plugins-generators-sshbase` which automates ssh key management)
 #. Generating client per-entry installation decision-lists
 
 Enabling Plugins
@@ -84,7 +84,7 @@ Plugin Roles (in 1.0)
 
 In version 1.0, plugins have been refactored into a series of roles. This are fine-grained plugin capabilities that govern how the server core interacts with plugins.
 
-More details can be found in :ref:`plugins-plugin-roles`
+More details can be found in :ref:`server-plugins-plugin-roles`
 
 .. toctree::
    :hidden:
diff --git a/doc/plugins/plugin-roles.txt b/doc/server/plugins/plugin-roles.txt
index 5bfa815c7..2ce7e21ff 100644
--- a/doc/plugins/plugin-roles.txt
+++ b/doc/server/plugins/plugin-roles.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-plugin-roles:
+.. _server-plugins-plugin-roles:
 
 ============
 Plugin Roles
diff --git a/doc/plugins/probes.txt b/doc/server/plugins/probes.txt
index 45e967423..57f12a840 100644
--- a/doc/plugins/probes.txt
+++ b/doc/server/plugins/probes.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-probes:
+.. _server-plugins-probes:
 
 ======
 Probes
@@ -8,7 +8,8 @@ Probes
 
 At times you need to gather information from a client machine before you can generate its configuration.  For example, if some of your machines have both a local scratch disk and a system disk while others only have the system disk, you would want to know this information to correctly generate an `/etc/auto.master` autofs config file for each type.  Here we will look at how to do this.
 
-First you will need to set up the TCheetah plugin, as described on the :ref:`plugins-generators-tcheetah` page.
+First you will need to set up the TCheetah plugin, as described on the
+:ref:`server-plugins-generators-tcheetah` page.
 
 Next, we need to create a `Probes` directory in our toplevel repository location::
 
diff --git a/doc/plugins/statistics/dbstats.txt b/doc/server/plugins/statistics/dbstats.txt
index 942f2ba7a..fed44f11c 100644
--- a/doc/plugins/statistics/dbstats.txt
+++ b/doc/server/plugins/statistics/dbstats.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-statistics-dbstats:
+.. _server-plugins-statistics-dbstats:
 
 =======
 DBStats
diff --git a/doc/plugins/statistics/statistics.txt b/doc/server/plugins/statistics/statistics.txt
index 8a00dbe7d..d16f5a828 100644
--- a/doc/plugins/statistics/statistics.txt
+++ b/doc/server/plugins/statistics/statistics.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-statistics-statistics:
+.. _server-plugins-statistics-statistics:
 
 ==========
 Statistics
diff --git a/doc/server/plugins/structures/base.txt b/doc/server/plugins/structures/base.txt
new file mode 100644
index 000000000..8f28997b0
--- /dev/null
+++ b/doc/server/plugins/structures/base.txt
@@ -0,0 +1,14 @@
+.. -*- mode: rst -*-
+
+.. _server-plugins-structures-base:
+
+====
+Base
+====
+
+The Base plugin is a structure plugin that provides the ability to add
+lists of unrelated entries into client configuration entry inventories.
+Base works much like Bundler in its file format. The main difference
+between Base and Bundler is that Base files are included in all clients'
+configuration whereas bundles must be included explicitly in your
+Metadata. See the :ref:`server-plugins-structures-bundler` page for details.
diff --git a/doc/plugins/structures/bundler.txt b/doc/server/plugins/structures/bundler.txt
index 694698c55..5437b35f1 100644
--- a/doc/plugins/structures/bundler.txt
+++ b/doc/server/plugins/structures/bundler.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-structures-bundler:
+.. _server-plugins-structures-bundler:
 
 =======
 Bundler
@@ -16,15 +16,15 @@ The following is an annotated copy of a bundle:
 
     <Bundle revision='$Revision: 2668 $' name='ssh' version='2.0'
             origin='https://svn.mcs.anl.gov/repos/bcfg/trunk/repository/Bundler/ssh.xml'>
-      <ConfigFile name='/etc/ssh/ssh_host_dsa_key'/>
-      <ConfigFile name='/etc/ssh/ssh_host_rsa_key'/>
-      <ConfigFile name='/etc/ssh/ssh_host_dsa_key.pub'/>
-      <ConfigFile name='/etc/ssh/ssh_host_rsa_key.pub'/>
-      <ConfigFile name='/etc/ssh/ssh_host_key'/>
-      <ConfigFile name='/etc/ssh/ssh_host_key.pub'/>
-      <ConfigFile name='/etc/ssh/sshd_config'/>
-      <ConfigFile name='/etc/ssh/ssh_config'/>
-      <ConfigFile name='/etc/ssh/ssh_known_hosts'/>
+      <Path name='/etc/ssh/ssh_host_dsa_key'/>
+      <Path name='/etc/ssh/ssh_host_rsa_key'/>
+      <Path name='/etc/ssh/ssh_host_dsa_key.pub'/>
+      <Path name='/etc/ssh/ssh_host_rsa_key.pub'/>
+      <Path name='/etc/ssh/ssh_host_key'/>
+      <Path name='/etc/ssh/ssh_host_key.pub'/>
+      <Path name='/etc/ssh/sshd_config'/>
+      <Path name='/etc/ssh/ssh_config'/>
+      <Path name='/etc/ssh/ssh_known_hosts'/>
       <Group name='rpm'>
         <Package name='openssh'/>
         <Package name='openssh-askpass'/>
@@ -112,7 +112,9 @@ In some cases, configuration files need to include the client's hostname in thei
         <Path name='/etc/package-${metadata.hostname}'/>
     </Bundle>
 
-Depending on the circumstance, these configuration files can either be handled by individual entries in :ref:`plugins-generators-cfg`, :ref:`plugins-generators-tcheetah`, or :ref:`plugins-generators-tgenshi`, or can be mapped to a single entry by using the [wiki:altsrc] feature.
+Depending on the circumstance, these configuration files can either be
+handled by individual entries in :ref:`server-plugins-generators-cfg`,
+:ref:`server-plugins-generators-tcheetah`, or :ref:`server-plugins-generators-tgenshi`, or can be mapped to a single entry by using the [wiki:altsrc] feature.
 
 In this example, configuration file names are built using probed results from the client. getmac is a probe that gathers client MAC addresses and returns them in a newline delimited string.
 
diff --git a/doc/plugins/version/bzr.txt b/doc/server/plugins/version/bzr.txt
index 58cc1930f..c86117502 100644
--- a/doc/plugins/version/bzr.txt
+++ b/doc/server/plugins/version/bzr.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-version-bzr:
+.. _server-plugins-version-bzr:
 
 ===
 Bzr
diff --git a/doc/plugins/version/fossil.txt b/doc/server/plugins/version/fossil.txt
index 36c0c204a..e73979509 100644
--- a/doc/plugins/version/fossil.txt
+++ b/doc/server/plugins/version/fossil.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-version-fossil:
+.. _server-plugins-version-fossil:
 
 ======
 Fossil
diff --git a/doc/plugins/version/git.txt b/doc/server/plugins/version/git.txt
index 8ec30bc6a..0bbef7288 100644
--- a/doc/plugins/version/git.txt
+++ b/doc/server/plugins/version/git.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-version-git:
+.. _server-plugins-version-git:
 
 ===
 Git
diff --git a/doc/plugins/version/svn.txt b/doc/server/plugins/version/svn.txt
index 284ed5dea..f1deda3e0 100644
--- a/doc/plugins/version/svn.txt
+++ b/doc/server/plugins/version/svn.txt
@@ -1,6 +1,6 @@
 .. -*- mode: rst -*-
 
-.. _plugins-version-svn:
+.. _server-plugins-version-svn:
 
 ===
 Svn
diff --git a/doc/server/reports/dynamic.txt b/doc/server/reports/dynamic.txt
new file mode 100644
index 000000000..a22132afb
--- /dev/null
+++ b/doc/server/reports/dynamic.txt
@@ -0,0 +1,172 @@
+.. -*- mode: rst -*-
+
+.. _server-reports-dynamic:
+
+==============================
+Bcfg2 Dynamic Reporting System
+==============================
+
+Installation
+============
+
+Overview
+--------
+
+Installation of the new reporting system requires installation of a python module and configuration of the Apache webserver with a virtual host. Additionally, until fully integrated, periodically an "import script" must be executed via Cron or similar mechanism.
+
+Versions 0.9.5pre1 and greater no longer need to be installed at the root url for a given host, and therefore no longer require their own virtual host.
+
+Prerequisites
+-------------
+
+* sqlite3
+* pysqlite2
+* `Django <http://www.djangoproject.com>`_
+* mod-python
+
+Install
+-------
+
+'''setup bcfg2.conf or bcfg2-web.conf'''
+
+Be sure to include the specified fields included the example bcfg2.conf file. These can be specified in either /etc/bcfg2.conf, if it is readable by the webserver user, or /etc/bcfg2-web.conf.
+
+
+'''Install skeleton database'''
+
+Inside the {{{bcfg2-tarball/examples/}}} directory from the tarball you will find {{{brpt.sqlite}}}. Copy this file to <path-to-bcfg2-repository>/etc/brpt.sqlite
+
+If you are not using sqlite (the default choice), please see the "Notes on Alternative Databases" section below.
+
+At this point we can import statistics date in to the database from your {{{clients.xml}}} and {{{statistics.xml}}} files.
+
+execute the following: {{{python .../site-packages/Bcfg2/Server/Reports/importscript.py }}}
+
+At this point you shouldn't get any errors or tracebacks. Common problems include incorrect installation of the pysqlite2 module.
+
+'''Next we configure Apache:'''
+
+An example site config is included below for the vhost "reports.mcs.anl.gov"::
+
+    <VirtualHost reports.mcs.anl.gov>
+            ServerAdmin webmaster@mcs.anl.gov
+            ServerName reports.mcs.anl.gov
+            DocumentRoot /var/www/reports
+            <Directory /var/www/reports>
+                    Order deny,allow
+                    Deny from all
+                    Allow from localhost #you may want to change this
+                    AllowOverride None
+            </Directory>
+
+            # Possible values include: debug, info, notice, warn, error, crit,
+            # alert, emerg.
+            LogLevel warn
+
+            ServerSignature Off
+
+            # Stop TRACE/TRACK vulnerability
+            <IfModule mod_rewrite.c>
+                    RewriteEngine on
+                    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
+                    RewriteRule .* - [F]
+            </IfModule>
+    <Location "/">
+            SetHandler python-program
+            PythonHandler django.core.handlers.modpython
+            SetEnv DJANGO_SETTINGS_MODULE Bcfg2.Server.Reports.settings
+            PythonDebug On
+    </Location>
+    <Location "/site_media/">
+            SetHandler None
+    </Location>
+    </VirtualHost>
+
+The first three lines of this configuration must be customized per site.
+
+The {{{bcfg2-tarball/reports/site_media/}}} directory needs to be copied to {{{/var/www/reports/site_media/}}} It could live anywhere; as long as the contents are accessible on the virtual host at {{{/site_media/}}}. 
+
+At this point you should be able to point your web browser to the virtualhost you created '''and see the new reports'''.
+
+One final step is to configure your system to import statistics data regularly. 
+execute the following: {{{python .../site-packages/Bcfg2/Server/Reports/importscript.py }}}
+
+(''Versions 0.8.7 and prior must specify: {{{python .../site-packages/Bcfg2/Server/Reports/importscript.py-c <repo>/Metadata/clients.xml -s <repo>/etc/statistics.xml}}} '')
+
+on a regular basis, perhaps as often as every 5 or 10 minutes or as infrequent as daily, so your reports are always up to date.
+
+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 encounter any problems or have suggestions for these instructions feedback is welcome and encouraged.''
+
+Summary and Features
+====================
+
+The new reporting system was implemented to address a number of deficiencies in the previous system. By storing statistics data in a relational database, we are now able to view and analyze more information about the state of the configuration, including information about previous configuration. Specific features in the new system include:
+
+* The ability to look at past statistics information. [[Image(summary_cal.jpg, 30%, right)]]
+* More recent data concerning hosts. The import script may be run quite often, updating the database that contains all statistics information. In the future we anticipate development of a database based statistics module for the server that will allow statistics updates to happen immediately as configuration changes happen.
+* Additional information display in reports. Primarily, reasons for configuration item verification failure are now accessible. This additional data is provided only by the most recent client. 
+* Instead of static pages, pages are generated on the fly, allowing users to drill down to find out about a specific host, rather than have one huge page with too much information.
+
+Planned improvements include
+============================
+
+* Accounts, customized displays for each admin. And privacy of config data.
+* Config browsing capabilities; to look at your config in an interesting way.
+* Fixing all the known bugs from below. 
+
+Unfortunately with all the improvements, there are a few less exciting elements about the new reporting system. The new reporting system moves away from static pages and towards a real web application, which causes mainly problems with dependancies and makes installation and more difficult. This should become less of a problem over time as Django is packaged and we develop a better installation process for a web app. This should become clear when reading the Installation section that follows.
+
+Usage
+=====
+
+You can use these new reports in tandem with the old system. Currently the new reporting system simply periodically runs an importer script via cron. This imports the XML statistics and clients files to the relational database, building historical information. In the future, a new statistics module in the server will allow direct writing to the database whenever a configuration interaction occurs, which will make the reports always up to date.
+
+bcfg2-reports (command line script)
+-----------------------------------
+
+bcfg2-reports allows you to retrieve data from the database about clients, and the states of their current interactions. It also allows you to change the expired/unexpired states.
+
+The utility runs as a standalone application. It does, however, use the models from /src/lib/Server/Reports/reports/models.py.
+
+A number of different options can be used to change what bcfg2-reports
+displays::
+
+    Usage: python bcfg2-reports [option] ...
+
+    Options and arguments (and corresponding environment variables):
+    -a                     : shows all hosts, including expired hosts
+    -b NAME                : single-host mode - shows bad entries from the
+                             current interaction of NAME
+    -c                     : shows only clean hosts
+    -d                     : shows only dirty hosts
+    -e NAME                : single-host mode - shows extra entries from the
+                             current interaction of NAME
+    -h                     : shows help and usage info about bcfg2-reports
+    -s NAME                : single-host mode - shows bad and extra entries from
+                             the current interaction of NAME
+    -x NAME                : toggles expired/unexpired state of NAME
+    --badentry=KIND,NAME   : shows only hosts whose current interaction has bad
+                             entries in of KIND kind and NAME name; if a single
+                             argument ARG1 is given, then KIND,NAME pairs will be
+                             read from a file of name ARG1
+    --extraentry=KIND,NAME : shows only hosts whose current interaction has extra
+                             entries in of KIND kind and NAME name; if a single
+                             argument ARG1 is given, then KIND,NAME pairs will be
+                             read from a file of name ARG1
+    --fields=ARG1,ARG2,... : only displays the fields ARG1,ARG2,...
+                             (name,time,state)
+    --sort=ARG1,ARG2,...   : sorts output on ARG1,ARG2,... (name,time,state)
+    --stale                : shows hosts which haven't run in the last 24 hours
+
+Screenshots
+===========
+
+[[Image(summary_cal.jpg, 30%)]]
+[[Image(node_dropdown.jpg, 30%)]]
+[[Image(item_detail.jpg, 30%)]]
diff --git a/doc/server/reports/index.txt b/doc/server/reports/index.txt
new file mode 100644
index 000000000..986efc47d
--- /dev/null
+++ b/doc/server/reports/index.txt
@@ -0,0 +1,24 @@
+.. -*- mode: rst -*-
+
+.. _server-reports-index:
+
+The Bcfg2 Reporting System
+==========================
+
+Bcfg2's reporting system is its killer feature. It allows administrators to gain a broad understanding of the configuration state of their entire environment. It summarizes
+
+* Configuration changes and when they were made
+* Discrepancies between the specification and current client states
+
+  * Clients can be grouped by misconfiguration type
+
+* Configuration entries that are not specified
+* Overall client summaries according to these types
+
+There are two systems, the old system, which builds static reports based on a series of XSLT stylesheets and a new dynamic reporting system that uses django and a database backend. 
+
+.. toctree::
+   :maxdepth: 2
+
+   static
+   dynamic
diff --git a/doc/server/reports/static.txt b/doc/server/reports/static.txt
new file mode 100644
index 000000000..8b984f785
--- /dev/null
+++ b/doc/server/reports/static.txt
@@ -0,0 +1,80 @@
+.. -*- mode: rst -*-
+
+.. _server-reports-static:
+
+=============================
+Bcfg2 Static Reporting System
+=============================
+
+The Bcfg2 reporting system collects and displays information about the 
+operation of the Bcfg2 client, and the configuration states of target machines.
+
+Goals
+=====
+
+The reporting system provides an interface to administrators describing a few important tasks
+
+* Client configuration state, particularly aspects that do not match the configuration specification.
+  Information about bad and extra configuration elements is included.
+* Client execution results (a list of configuration elements that were modified)
+* Client execution performance data (including operation retry counts, and timings for several critical execution regions)
+
+This data can be used to understand the current configuration state of the 
+entire network, the operations performed by the client, how the configuration changes propagate, and 
+any reconfiguration operations that have failed.
+
+Retention Model
+===============
+
+The current reporting system stores statistics in an XML data store, by default to {{{<repo>/etc/statistics.xml}}}. It retains either 
+one or two statistic sets per host. If the client has a clean configuration state, the most recent (clean) record is retained. 
+If the client has a dirty configuration state, two records are retained. One record is the last 
+clean record. The other record is the most recent record collected, detailing the incorrect state.  
+
+This retention model, while non-optimal, does manage to persistently record most of the data that users would like. 
+
+Setup
+=====
+
+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.
+
+Output
+======
+
+Several output reports can be generated from the statistics store with the command line tool {{{bcfg2-build-reports}}}.
+
+* Nodes Digest
+* Nodes Individual
+* Overview Statistics
+* Performance
+
+The data generated by these reports can be delivered by several mechanisms:
+
+* HTML
+* Email
+* RSS
+
+Shortcomings and Planned Enhancements
+=====================================
+
+When designing the current reporting system, we were overly concerned with the potential explosion in data size over time.
+In order to address this, we opted to use the retention scheme described above. This approach has several shortcomings:
+
+* A comprehensive list of reconfiguration operations (with associated timestamps) isn't retained
+* Client results for any given day (except the last one) aren't uniformly retained. This means that inter-client analysis is 
+  difficult, if not impossible
+
+We plan to move to a database backend to address the dataset size problem and start retaining all information. The move to a 
+SQL backend will allow many more types of queries to be efficiently processed. It will also make on-demand reports simpler. 
+
+Other sorts of information would also be useful to track. We plan to add the ability to tag a particular configuration 
+element as security related, and include this in reports. This will aid in the effective prioritization of manual and 
+failed reconfiguration tasks. 
+
+Capability Goals (posed as questions)
+-------------------------------------
+
+* What machines have not yet applied critical updates?
+* How long did critical updates take to be applied?
+* What configuration did machine X have on a particular date?
+* When did machine X perform configuration update Y?
diff --git a/doc/unsorted/annotated_examples.txt b/doc/unsorted/annotated_examples.txt
new file mode 100644
index 000000000..99c6f774c
--- /dev/null
+++ b/doc/unsorted/annotated_examples.txt
@@ -0,0 +1,186 @@
+.. -*- mode: rst -*-
+
+.. _unsorted-annotated_examples:
+
+==================
+Annotated Examples
+==================
+
+ntp example
+===========
+
+Author: Jason Pepas 
+
+Here is a series of example configurations for bcfg2, each introducing another layer of functionality.  
+
+* After each change, run 'bcfg-repo-validate -v'.  
+* Run the server with 'bcfg2-server -v'.  
+* Update the client with 'bcfg2 -v -d -n'. (will not actually make client changes)
+
+package only
+------------
+
+Our example starts with the bare minimum configuration setup.  We have a client, a profile group, a list of packages, and a base configuration.
+
+::
+
+    # cat Metadata/clients.xml 
+    <Clients version='3.0'>
+    <Client profile='fedora' pingable='N' pingtime='0' name='foo.bar.com'/>
+    </Clients>
+
+    # cat Metadata/groups.xml 
+    <Groups version='3.0'>
+    <Group profile='true' name='fedora' toolset='rh'/>
+    </Groups>
+
+    # cat Base/base.xml 
+    <Base>
+    <Group name='fedora'>
+    <Package name='ntp'/>
+    </Group>
+    </Base>
+
+    # cat Pkgmgr/packages.xml
+    <PackageList type='rpm' priority='0'>
+    <Package name='ntp' version='4.2.0.a.20050816-11.FC5'/>
+    </PackageList>
+
+add service
+-----------
+
+Configure the service, and add it to the base.::
+
+    # cat Svcmgr/services.xml 
+    <Services priority='0'>
+    <Service name='ntpd' status='on'/>
+    </Services>
+
+    # cat Base/base.xml 
+    <Base>
+    <Group name='fedora'>
+    <Package name='ntp'/>
+    <Service name='ntpd'/>
+    </Group>
+    </Base>
+
+add config file
+---------------
+
+Setup an etc directory structure, and add it to the base.::
+
+    # cat Cfg/etc/ntp.conf/ntp.conf 
+    server ntp1.utexas.edu
+
+    # cat Base/base.xml 
+    <Base>
+    <Group name='fedora'>
+    <Package name='ntp'/>
+    <Service name='ntpd'/>
+    <ConfigFile name='/etc/ntp.conf'/>
+    </Group>
+    </Base>
+
+create a bundle
+---------------
+
+The above configuration layout works fine for a single service, but
+that method of organization would quickly become a nightmare as you
+approach the number of packages, services, and config files required
+to represent a fully configured host.  Bundles allow the grouping of
+related configuration entries that are used to provide a single
+service. This is done for several reasons:
+
+* Grouping related things in one place makes it easier to add those
+  entries for a multiple groups of clients
+* Grouping entries into bundles makes their validation occur
+  collectively. This means that config files can override the
+  contents of packages. Also, config files are rechecked after
+  packages are upgraded, so that they can be repaired if the package
+  install clobbered them. 
+* Services associated with a bundle get restarted whenever any
+  entity in that bundle is modified. This ensures that new
+  configuration files and software are used after installation.
+
+The config file, package, and
+service are really all related components describing the idea of an
+ntp client, so they should be logically grouped together.  We use a
+bundle to accomplish this.::
+
+    # cat Bundler/ntp.xml
+    <Bundle name='ntp' version='2.0'>
+    <Package name='ntp'/>
+    <Service name='ntpd'/>
+    <ConfigFile name='/etc/ntp.conf'/>
+    </Bundle>
+
+After this bundle is created, it must be associated with a group (or
+groups). Add a bundle child element to the group(s) which should install this bundle.::
+
+
+    # cat Metadata/groups.xml
+    <Groups>
+    ...
+    <Group name='fedora'>
+      <Bundle name='ntp'/>
+    </Group>
+    ...
+    </Groups>
+
+Once this bundle is created, a client reconfigure will install these
+entries. If any are modified, then the ntpd service will be
+restarted. If you only want ntp configurations to be updated (and
+nothing else), the bcfg2 client can be run with a -b <bundle name>
+option that will only update entries in the specified bundle.
+
+mysql example
+=============
+
+Author: Patrick Ruckstuhl
+
+I had some time ago to continue with putting my configuration into
+bcfg2 and maybe this helps someone else.
+
+I added a new bundle:
+
+.. code-block: xml
+
+    <Bundle name="mysql-server" version="3.0">
+       <ConfigFile name="/root/bcfg2-install/mysql/users.sh"/>
+       <ConfigFile name="/root/bcfg2-install/mysql/users.sql"/>
+       <PostInstall name="/root/bcfg2-install/mysql/users.sh"/>
+       <Package name="mysql-server-4.1"/>
+       <Service name="mysql"/>
+    </Bundle>
+
+The `users.sh` script looks like this:
+
+.. code-block: sh
+
+    #!/bin/sh
+
+    mysql --defaults-extra-file=/etc/mysql/debian.cnf mysql \
+        < /root/bcfg2-install/mysql/users.sql
+
+On debian there is a user account in `/etc/mysql/debian.cnf` automatically created, but you could also (manually) create a user in the database that has enough permissions and add the login information in a file yourself. This file looks like this::
+
+    [client]
+    host     = localhost
+    user     = debian-sys-maint
+    password = XXXXXXXXXX
+
+The `users.sql` looks like this::
+
+    DELETE FROM db;
+    INSERT INTO db VALUES ('localhost', 'phpmyadmin', 'pma', 'Y', 'Y',
+    'Y', 'Y', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N');
+
+    DELETE FROM user WHERE User <> 'debian-sys-maint';
+    INSERT INTO user VALUES ('localhost', 'root', 'XXXXXXXXXXX', 'Y', 'Y',
+    'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y',
+    'Y', 'Y', 'Y', 'Y', 'Y', '', '', '', '', 0, 0, 0);
+    INSERT INTO user VALUES ('localhost', 'pma', '', 'N', 'N', 'N', 'N',
+    'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N', 'N',
+    'N', 'N', 'N', '', '', '', '', 0, 0, 0);
+
+    FLUSH PRIVILEGES;
diff --git a/doc/unsorted/index.txt b/doc/unsorted/index.txt
index 63426c774..17feb13e6 100644
--- a/doc/unsorted/index.txt
+++ b/doc/unsorted/index.txt
@@ -13,14 +13,12 @@ list below.
 
 .. _TitleIndex: https://trac.mcs.anl.gov/projects/bcfg2/wiki/TitleIndex
 
-* `Annotated Examples`
 * `ManualPages`
 * `NewDynamicReports`
 * `NewDynamicReportsInstallation`
 * `News`
 * `Overview`
 * `ParanoidMode`
-* `Plugins`
 * `Plugins/Account`
 * `Plugins/Actions`
 * `Plugins/Bundler/examples`
@@ -66,19 +64,10 @@ list below.
 * `QuickStart3`
 * `RecentChanges`
 * `RefactorClient`
-* `Reports`
-* `Reports/Dynamic`
-* `Reports/Dynamic/Installation`
-* `Reports/Static`
-* `SandBox`
 * `SchemaEvolution`
 * `SecurityDevPlan`
 * `ServerSideOverview`
-* `TGenshi/examples`
 * `TGenshi/examples/Templated_Access`
-* `TGenshi/examples/bcfg2_cron`
-* `TGenshi/examples/clients.xml`
-* `TGenshi/examples/test`
 * `TOC`
 * `TrackingDevelopmentTrunk`
 * `Troubleshooting`
diff --git a/doc/unsorted/windows.txt b/doc/unsorted/windows.txt
index 33b45d67d..128bc52d6 100644
--- a/doc/unsorted/windows.txt
+++ b/doc/unsorted/windows.txt
@@ -15,7 +15,8 @@ Notes on possible Windows support
 Services
 ========
 
-With the exception of 32/64 bit issues, Windows Services support should be pretty trivial; it would differ from *nix services in that it would be done via WMI API calls and not a 3rd party python module or wrapping a binary.
+With the exception of 32/64 bit issues, Windows Services support should
+be pretty trivial; it would differ from \*nix services in that it would be done via WMI API calls and not a 3rd party python module or wrapping a binary.
 
 Registry
 ========
@@ -25,7 +26,8 @@ The best way of handling the registry may be to map it into a file-based represe
 Files
 =====
 
-For a first run there may be some way of utilizing [http://cygwin.com/ cygwin] to make use of the existing *nix POSIX module for manipulating files. There would probably need to be some changes to deal with the fact that open files can't be manipulated/moved/deleted at all in Windows (other than to do some registry magic that makes the changes on the next reboot).
+For a first run there may be some way of utilizing [http://cygwin.com/
+cygwin] to make use of the existing \*nix POSIX module for manipulating files. There would probably need to be some changes to deal with the fact that open files can't be manipulated/moved/deleted at all in Windows (other than to do some registry magic that makes the changes on the next reboot).
 
 Packages
 ========
@@ -39,13 +41,17 @@ Prior FLOSS Art
 
 * [http://www.autoitscript.com/autoit3/ AutoIt] - For dealing with packages that don't have a silent install option
 * [http://www.opensysadmin.com/trac/ticket/4 French Stuff]
+
  * [http://ocsinventory.sourceforge.net/ Open Computers and Software Inventory - Next Generation]
  * [http://www.glpi-project.org/spip.php?lang=en GLPI - Gestionnaire libre de parc informatique]
+
 * Javascript thing a colleague of Desai's at ANL wrote - Desai was going to see if this can be released
 * [http://sial.org/howto/cfengine/windows/ Managing Windows with CFEngine and Perl]
 * [http://www.dmst.aueb.gr/dds/sw/outwit/ Outwit] - Small unixy utilities for Windows stuff like the registry and clipboard
 * [http://www.cfengine.org/docs/cfengine-NT/ Porting cfengine to Windows NT]
 * [http://isg.ee.ethz.ch/tools/realmen/ Real Men Don't Click] - Tobi Oetiker's stuff
+
  * [http://isg.ee.ethz.ch/tools/realmen/res/index.en.html More Prior FLOSS Art]
+
 * [http://unattended.sourceforge.net/ Unattended] - Bare Metal Installs, Package Management
 * [http://wpkg.org/ WPKG] - Package Management