removed deprecated plugins: TGenshi, TCheetah, Account, Hostbase, Snapshots, Statistics, Editor

12 files changed, 4 insertions, 1033 deletions

diff --git a/doc/reports/static.txt b/doc/reports/static.txt
deleted file mode 100644
index 00c1867f8..000000000
--- a/doc/reports/static.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _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``. 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/server/admin/index.txt b/doc/server/admin/index.txt
index ee03cedda..8ea765aac 100644
--- a/doc/server/admin/index.txt
+++ b/doc/server/admin/index.txt
@@ -24,7 +24,6 @@ functionality. Available modes are listed below.
    perf
    pull
    query
-   snapshots
    tidy
    viz
    xcmd
diff --git a/doc/server/admin/snapshots.txt b/doc/server/admin/snapshots.txt
deleted file mode 100644
index 25a7286c2..000000000
--- a/doc/server/admin/snapshots.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-admin-snapshots:
-
-snapshots
-=========
-
-Interact with the Snapshots system.
diff --git a/doc/server/index.txt b/doc/server/index.txt
index 2ccc9c923..42abb454c 100644
--- a/doc/server/index.txt
+++ b/doc/server/index.txt
@@ -26,7 +26,6 @@ clients.
    admin/index
    configurationentries
    info
-   snapshots/index
    bcfg2-info
    selinux
    configuration
diff --git a/doc/server/plugins/generators/account.txt b/doc/server/plugins/generators/account.txt
deleted file mode 100644
index 99c35c814..000000000
--- a/doc/server/plugins/generators/account.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-plugins-generators-account:
-
-=======
-Account
-=======
-
-The account plugin manages authentication data, including
-
-* ``/etc/passwd``
-* ``/etc/group``
-* ``/etc/security/limits.conf``
-* ``/etc/sudoers``
-* ``/root/.ssh/authorized_keys``
-
-User access data is stored in three files in the Account directory:
-
-* superusers (a list of users who always have root privs)
-* rootlist (a list of user:host pairs for scoped root privs)
-* useraccess (a list of user:host pairs for login access)
-
-SSH keys are stored in files named $username.key; these are installed
-into root's authorized keys for users in the superusers list as well as
-for the pertitent users in the rootlike file (for the current system).
-
-Authentication data is read in from (static|dyn).(passwd|group) The static
-ones are for system local ones, while the dyn. versions are for external
-synchronization (from ldap/nis/etc). There is also a static.limits.conf
-that provides the limits.conf header and any static entries.
-
-Files in the Account directory:
-
-``<username>.key``
-
-    **Format**: The SSH public key for user <username>.
-
-        If the user is in the "rootlike" or "superusers" group, these
-        keys will be appended to ``/root/.ssh/auth``
-
-``useraccess``
-
-    **Format**: "user:hostname" on each line.
-
-        Describes who may login where (via PAMs
-        ``/etc/security/limits.conf``). Everybody else will be denied
-        access.(?)
-
-    **Example**:
-
-        If Alice should be able to access host "foo", Bob should access
-        "foo" and "bar"::
-
-                 alice:foo.example.com
-                 bob:foo.example.com
-                 bob:bar.example.com
-
-``rootlike``
-
-    **Format**: "user:hostname" on each line.
-
-        Describes who will be allowed root access where. The user may
-        login via public key and use sudo.
-
-    **Example**:
-
-        If Chris should be root only on host "foo"::
-
-                 chris:foo.example.com
-
-``superusers``
-
-    **Format**: usernames, separated by spaces or newlines. (Any whitespace that makes pythons split() happy.)
-
-        Describes who will be allowed root access on all hosts. The user
-        may login via public key and use sudo.
-
-    **Example**:
-
-        Daniel, Eve and Faith are global admins::
-
-                 daniel eve
-                 faith
-
-``static.passwd``, ``static.group``
-
-    **Format**: Lines from ``/etc/passwd`` or ``/etc/group``
-
-        These entries are appended to the passwd and group files
-        (in addition to the auto-generated entries from "useraccess",
-        "rootlike" and "superusers" above) without doing anything else.
-
-``dyn.passwd``, ``dyn.group``
-
-    **Format**: Lines from ``/etc/passwd`` or ``/etc/group``
-
-        Similar to "static.*" above, but for entries that are managed "on
-        the network" (yp, LDAP, ...), so it is most likely periodically
-        (re)filled.
-
-``static.limits.conf``
-
-    **Format**: Lines from ``/etc/security/limit.conf``
-
-        These limits will be appended to limits.conf (in addition to
-        the auto-generated entries from "useraccess", "rootlike" and
-        "superusers" above).
-
-``static.sudoers``
-
-    **Format**: Lines from ``/etc/sudoers``
-
-        These lines will be appended to to sudoers file (in addition
-        to the auto-generated entries from "useraccess", "rootlike" and
-        "superusers" above).
diff --git a/doc/server/plugins/generators/cfg.txt b/doc/server/plugins/generators/cfg.txt
index 1cb4b8727..4d78258d8 100644
--- a/doc/server/plugins/generators/cfg.txt
+++ b/doc/server/plugins/generators/cfg.txt
@@ -102,9 +102,8 @@ Genshi Templates
 ----------------
 
 Genshi templates allow you to use the `Genshi
-<http://genshi.edgewall.org>`_ templating system.  This is similar to
-the deprecated :ref:`server-plugins-generators-tgenshi-index` plugin.
-Genshi templates should be named with a ``.genshi`` extension, e.g.::
+<http://genshi.edgewall.org>`_ templating system.  Genshi templates
+should be named with a ``.genshi`` extension, e.g.::
 
     % ls Cfg/etc/motd
     info.xml  motd.genshi
@@ -214,9 +213,8 @@ Cheetah Templates
 -----------------
 
 Cheetah templates allow you to use the `cheetah templating system
-<http://www.cheetahtemplate.org/>`_.  This is similar to
-the deprecated :ref:`server-plugins-generators-tcheetah` plugin.
-Cheetah templates should be named with a ``.cheetah`` extension, e.g.::
+<http://www.cheetahtemplate.org/>`_.  Cheetah templates should be
+named with a ``.cheetah`` extension, e.g.::
 
     % ls Cfg/etc/motd
     info.xml  motd.cheetah
diff --git a/doc/server/plugins/generators/hostbase.txt b/doc/server/plugins/generators/hostbase.txt
deleted file mode 100644
index c6007f70e..000000000
--- a/doc/server/plugins/generators/hostbase.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-plugins-generators-hostbase:
-
-========
-Hostbase
-========
-
-IP management system built on top of Bcfg2. It has four main parts: a
-django data model, a web frontend, command-line utilities, and a Bcfg2
-plugin that generates dhcp, dns, and yp configuration files.
-
-Installation
-============
-
-Installation of Hostbase requires installation of a python module,
-configuration of database (mysql or postgres), and configuration of an
-Apache webserver with mod_python. Hostbase was developed using MySQL,
-so this document is aimed at MySQL users.
-
-Prerequisites
--------------
-
-* `mysql`_
-* `python-mysqldb`_
-* `Django`_
-
-.. _Django: http://www.djangoproject.com
-.. _python-mysqldb: http://mysql-python.sourceforge.net/MySQLdb.html
-.. _mysql: http://www.mysql.com/
-
-Configure the database
-----------------------
-
-Create the hostbase database and a user.  For MySQL users::
-
-    mysql> CREATE DATABASE hostbase
-    mysql> quit
-
-    systemprompt#:  mysql -u root hostbase
-    mysql> GRANT ALL PRIVILEGES ON *.* TO hostbaseuser@mycomputer.private.net IDENTIFIED
-           BY 'password' WITH GRANT OPTION;
-    mysql> quit
-
-As of Bcfg2 v0.8.7 configuration options for Hostbase have moved to
-``/etc/bcfg2.conf``.  There is an example bcfg2.conf with Hostbase
-options located at ``bcfg2-tarball/examples/bcfg2.confHostbase``.
-Edit the hostbase options to correspond to the database you've
-initialized and copy the configuration to ``/etc/bcfg2.conf``.  To
-finish creating the database, from your ``path to
-python/Bcfg2/Server/Hostbase`` directory, run ``python manage.py
-syncdb`` to do all table creation.
-
-Configure the web interface
----------------------------
-
-Now it's possible to explore the Hostbase web interface.  For
-curiosity, you can run Django's built-in development server to take a
-peek.  Do this by running ``python manage.py runserver
-[servername:port]`` from your Hostbase directory.  Django will
-default to ``localhost:8000`` if no server or port is entered.  Now
-you can explore the web interface.  Try adding a host and a zone.
-You'll see that a ".rev" zone already exists.  This is where
-information for reverse files will go.
-
-For production, you'll want to have this configured for Apache with
-mod_python. Here is an example of how to configure Hostbase as a
-virtual host.
-
-.. code-block:: html
-
-    <VirtualHost hostbase.mcs.anl.gov:80>
-            ServerAdmin systems@mcs.anl.gov
-
-            DocumentRoot /var/www/hostbase/
-            <Directory />
-                    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>
-
-            Redirect / https://hostbase.mcs.anl.gov/
-    </VirtualHost>
-
-    <VirtualHost hostbase.mcs.anl.gov:443>
-            ServerAdmin systems@mcs.anl.gov
-
-            DocumentRoot /var/www/hostbase/
-            <Directory />
-                    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>
-
-            SSLEngine On
-            SSLCertificateFile /etc/apache2/ssl/hostbase_server.crt
-            SSLCertificateKeyfile /etc/apache2/ssl/hostbase_server.key
-
-    <Location "/">
-            SetHandler python-program
-            PythonHandler django.core.handlers.modpython
-            SetEnv DJANGO_SETTINGS_MODULE Bcfg2.Server.Hostbase.settings
-            PythonDebug On
-    </Location>
-    <Location "/site_media/">
-            SetHandler None
-    </Location>
-    </VirtualHost>
-
-
-You'll need to copy the contents of ``Hostbase/media`` into
-``/var/www/hostbase/site_media`` in this configuration to serve the
-correct css files.
-
-Enable the Hostbase plugin
---------------------------
-
-Now that the database is accessible and there is some data in it, you can
-enable the Hostbase plugin on your Bcfg2 server to start generating some
-configuration files.  All that needs to be done is to add ``Hostbase``
-to the end of the list of generators in your bcfg2.conf file.  To see
-what's being generated by Hostbase, fire up a Bcfg2 development server:
-``bcfg2-info``.  For more information on how to use the Bcfg2 development
-server, type help at the prompt.  For our purposes, type ``debug``.
-This will bring you to an interactive python prompt where you can access
-bcfg's core data.
-
-.. code-block:: python
-
-    for each in bcore.plugins['Hostbase'].filedata:
-        print each
-
-
-The above loop will print out the name of each file that was generated
-by Hostbase.  You can see the contents of any of these by typing ``print
-bcore.plugins['Hostbase'].filedata[filename]``.
-
-Create a bundle
----------------
-
-Bcfg2 needs a way to distribute the files generated by Hostbase.
-We'll do this with a bundle.  In bcfg's ``Bundler`` directory, touch
-``hostbase.xml``.
-
-.. code-block:: xml
-
-    <Bundle name='hostbase' version='0.1'>
-       <Package name='dhcp3-server'/>
-       <Package name='bind9'/>
-       <Service name='dhcp3-server'/>
-       <Service name='bind9'/>
-       <Path name='/etc/dhcp3/dhcpd.conf'/>
-       <Path name='/etc/bind/[your domain]'/>
-       <Path name='/etc/bind/xxx.xxx.xxx.rev'/>
-    </Bundle>
-
-The above example is a bundle that will deliver both dhcp and dns files.
-This can be trivially split into separate bundles.  It is planned that
-Hostbase will eventually be able to generate the list of ``Paths``
-in its bundles automatically.
-
-Do a Hostbase push
-------------------
-
-You'll want to be able to trigger the Hostbase plugin to rebuild
-it's config files and push them out when data has been modified
-in the database.  This can be done through and XMLRPC function
-available from the Bcfg2 server.  From a client that is configured
-to receive one or more hostbase bundles, you'll need to first
-edit your ``python/site-packages/Bcfg2/Client/Proxy.py`` file.
-Add ``'Hostbase.rebuildState'`` to the list of methods in the Bcfg2
-client proxy object.  The modified list is shown below:
-
-.. code-block:: python
-
-    class bcfg2(ComponentProxy):
-        '''bcfg2 client code'''
-        name = 'bcfg2'
-        methods = ['AssertProfile', 'GetConfig', 'GetProbes', 'RecvProbeData', 'RecvStats', 'Hostbase.rebuildState']
-
-Now copy the file ``hostbasepush.py`` from ``bcfg2/tools`` in the Bcfg2
-source to your machine.  When this command is run as root, it triggers
-the Hostbase to rebuild it's files, then runs the Bcfg2 client on your
-local machine to grab the new configs.
-
-NIS Authentication
-==================
-
-Django allows for custom authentication backends to its login procedure.
-Hostbase has an NIS authentication backend that verifies a user to be
-in the unix group allowed to modify Hostbase.
-
-To enable this feature:
-
-* first edit your ``Hostbase/settings.py`` file and uncomment
-  the line **Hostbase.backends.NISBackend** in the list of
-  *AUTHENTICATION_BACKENDS*
-* enter the name of the unix group you want to give access to Hostbase
-  in the *AUTHORIZED_GROUP* variable
-* in your ``Hostbase/hostbase/views.py`` file at the very bottom,
-  uncomment the block(s) of lines that give you the desired level
-  of access
-
-Hostbase will now direct the user to a login page if he or she is not
-authorized to view a certain page.  Users should log in with their
-regular Unix username and password.
diff --git a/doc/server/plugins/generators/tcheetah.txt b/doc/server/plugins/generators/tcheetah.txt
deleted file mode 100644
index ab147ce56..000000000
--- a/doc/server/plugins/generators/tcheetah.txt
+++ /dev/null
@@ -1,197 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-plugins-generators-tcheetah:
-
-========
-TCheetah
-========
-
-.. warning::
-
-    TCheetah is deprecated.  You should instead use
-    :ref:`server-plugins-generators-cfg-cheetah` in the Cfg plugin.
-
-This document reflects the ``TCheetah`` plugin.
-
-The ``TCheetah`` plugin allows you to use the `cheetah templating system
-<http://www.cheetahtemplate.org/>`_ to create files, instead of the
-various diff-based methods offered by the ``Cfg`` plugin. It also allows
-you to include the results of probes executed on the client in the
-created files.
-
-To begin, you will need to download and install the Cheetah templating
-engine from http://www.cheetahtemplate.org/.  Once it is installed,
-you can enable it by adding ``TCheetah`` to the ``plugins`` line in
-``/etc/bcfg2.conf`` on your Bcfg server.  For example::
-
-    plugins = Base,Bundler,Cfg,...,TCheetah
-
-The ``TCheetah`` plugin makes use of a ``Cfg``-like directory structure
-located in in a ``TCheetah`` subdirectory of your repository, usually
-``/var/lib/bcfg2/TCheetah``. Each file has a directory containing two
-files, ``template`` and ``info``. The template is a standard Cheetah
-template with two additions:
-
-* `self.metadata` is the client's :ref:`metadata <server-plugins-grouping-metadata-clientmetadata>`
-* `self.metadata.Properties.xdata` is an xml document of unstructured data
-
-The ``info`` file is formatted like ``:info`` files from Cfg.
-
-Mostly, people will want to use client metadata.
-
-File permissions
-================
-
-File permissions for entries handled by TCheetah are controlled via the
-use of :ref:`server-info` files. Note that you **cannot** use both a
-Permissions entry and a Path entry to handle the same file.
-
-self.metadata variables
-=======================
-
-self.metadata is an instance of the class ClientMetadata and documented
-:ref:`here <server-plugins-grouping-metadata-clientmetadata>`.
-
-self.metadata.Properties.xdata
-==============================
-
-.. note::
-
-    If you want to use Properties, you will need to enable the
-    :ref:`server-plugins-connectors-properties` plugin in
-    ``/etc/bcfg2.conf``.
-
-Properties.xdata is a python `ElementTree <http://codespeak.net/lxml/>`_
-object, loaded from the data in ``/var/lib/bcfg2/Properties/<properties
-file>.xml``. That file should have a ``Properties`` node at its root.
-
-Example ``Properties/example.xml``:
-
-.. code-block:: xml
-
-    <Properties>
-     <host>
-       <www.example.com>
-         <rootdev>/dev/sda</rootdev>
-       </www.example.com>
-     </host>
-    </Properties>
-
-You may use any of the ElementTree methods to access data in your
-template.  Several examples follow, each producing an identical result
-on the host 'www.example.com'::
-
-    $self.metadata.Properties['example.xml'].xdata.find('host').find('www.example.com').find('rootdev').text
-    $self.metadata.Properties['example.xml'].xdata.find('host').find($self.metadata.hostname).find('rootdev').text
-    ${self.metadata.Properties['example.xml'].xdata.xpath('host/www.example.com/rootdev')[0].text}
-    ${self.metadata.Properties['example.xml'].xdata.xpath('host/' + self.metadata.hostname + '/rootdev')[0].text}
-    #set $path = 'host/' + $self.metadata.hostname + '/rootdev'
-    ${self.metadata.Properties['example.xml'].xdata.xpath($path)[0].text}
-    ${self.metadata.Properties['example.xml'].xdata.xpath(path)[0].text}
-
-Other Variables
-===============
-
-* **Template.searchList(self)[1]['path']** is the Path name specified in a Bundle
-* **Template.searchList(self)[1]['source_path']** is the path to the TCheetah template on the Bcfg2 server
-
-Simple Example
-==============
-
-TCheetah works similar to Cfg in that you define all literal information
-about a particular file in a directory rooted at TGenshi/path_to_file.
-The actual file contents are placed in a file named `template` in that
-directory. Below is a simple example a file ``/foo``.
-
-``/var/lib/bcfg2/TCheetah/foo/template``
-
-.. code-block:: none
-
-    > buildfile /foo <clientname>
-    Hostname is $self.metadata.hostname
-    Filename is $Template.searchList(self)[1]['path']
-    Template is $Template.searchList(self)[1]['source_path']
-    Groups:
-    #for $group in $self.metadata.groups:
-     * $group
-    #end for
-    Categories:
-    #for $category in $self.metadata.categories:
-     * $category -- $self.metadata.categories[$category]
-    #end for
-
-    Probes:
-    #for $probe in $self.metadata.Probes:
-     * $probe -- $self.metadata.Probes[$probe]
-    #end for
-
-``/var/lib/bcfg2/TCheetah/foo/info``
-
-.. code-block:: none
-
-    mode: 624
-
-Output
-------
-
-The following output can be generated with bcfg2-info. Note that probe
-information is not persistent, hence, it only works when clients directly
-query the server. For this reason, bcfg2-info output doesn't reflect
-current client probe state.
-
-.. code-block:: xml
-
-    <Path type="file" name="/foo" owner="root" mode="0624" group="root">
-    Hostname is topaz.mcs.anl.gov
-    Filename is /foo
-    Template is /var/lib/bcfg2/TCheetah/foo/template
-    Groups:
-     * desktop
-     * mcs-base
-     * ypbound
-     * workstation
-     * xserver
-     * debian-sarge
-     * debian
-     * a
-    Categories:
-     * test -- a
-
-    Probes:
-    </Path>
-
-Example: Replace the crontab plugin
-===================================
-
-In many cases you can use the TCheetah plugin to avoid writing custom
-plugins in Python. This example randomizes the time of cron.daily
-execution with a stable result. Cron.daily is run at a consistent,
-randomized time between midnight and 7am.::
-
-    #import random
-    #silent random.seed($self.metadata.hostname)
-
-    # /etc/crontab: system-wide crontab
-    # Unlike any other crontab you don't have to run the `crontab`
-    # command to install the new version when you edit this file.
-    # This file also has a username field, that none of the other crontabs do.
-
-    SHELL=/bin/sh
-    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin://bin
-
-    # m h dom mon dow user  command
-    17 *    * * *   root    run-parts --report /etc/cron.hourly
-    $random.randrange(0,59) $random.randrange(0,6)    * * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
-    47 6    * * 7   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly
-    52 6    1 * *   root    test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly.
-
-.. note:: Comments and Cheetah
-    As Cheetah processes your templates it will consider hash "#" style
-    comments to be actual comments in the template and will strip them
-    from the final config file.  If you would like to preserve the comment
-    in the final config file you need to escape the hash character '\#'
-    which will tell Cheetah (and Python) that you do in fact want the
-    comment to appear in the final config file.::
-
-        # This is a comment in my template which will be stripped when it's processed through Cheetah
-        \# This comment will appear in the generated config file.
diff --git a/doc/server/plugins/generators/tgenshi.txt b/doc/server/plugins/generators/tgenshi.txt
deleted file mode 100644
index 43a02f253..000000000
--- a/doc/server/plugins/generators/tgenshi.txt
+++ /dev/null
@@ -1,213 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-plugins-generators-tgenshi-index:
-
-=======
-TGenshi
-=======
-
-.. warning::
-
-    The TGenshi plugin is deprecated.  You should instead use
-    :ref:`server-plugins-generators-cfg-genshi` in the Cfg plugin.
-
-This page documents the TGenshi plugin. This plugin works with version
-0.4 and newer of the genshi library.
-
-The TGenshi plugin allows you to use the `Genshi
-<http://genshi.edgewall.org>`_ templating system to create files,
-instead of the various diff-based methods offered by the Cfg
-plugin. It also allows you to include the results of probes executed
-on the client in the created files.
-
-To begin, you will need to download and install the Genshi templating engine.
-
-To install on CentOS or RHEL, run::
-
-    sudo yum install python-genshi
-
-Once it is installed, you can enable it by adding ``TGenshi`` to the
-generators line in ``/etc/bcfg2.conf`` on your Bcfg server. For example::
-
-    plugins = Base,Bundler,Cfg,...,TGenshi
-
-The TGenshi plugin makes use of a Cfg-like directory structure
-located in in a TGenshi subdirectory of your repository, usually
-``/var/lib/bcfg2/TGenshi``. Each file has a directory containing two file
-types, template and info. Templates are named according to the genshi
-format used; template.txt uses the genshi text format, and template.xml
-uses the XML format.
-
-If used with Genshi 0.5 or later the plugin also supports the `new
-style
-<http://genshi.edgewall.org/wiki/Documentation/0.5.x/text-templates.html>`_
-text template format for files named template.newtxt. One of the
-advantages of the new format is that it does not use # as a command
-delimiter, making it easier to utilize for configuration files that
-use # as a comment character.
-
-Only one template format may be used per file served. Info files are
-identical to those used in ``Cfg``, and ``info.xml`` files are
-supported.
-
-Inside of templates
-===================
-
-* **metadata** is the client's :ref:`metadata
-  <server-plugins-grouping-metadata-clientmetadata>`
-* **metadata.Properties** is an xml document of unstructured data (only
-  available when used in conjunction with the
-  :ref:`server-plugins-connectors-properties` plugin)
-* **name** is the path name specified in bcfg
-* **path** is the path to the TGenshi template.  It starts with a
-    leading slash, and is relative to the Bcfg2 specification root.
-    E.g., ``/Cfg/etc/foo.conf/foo.conf.genshi`` or
-    ``/TGenshi/etc/foo.conf/template.newtxt.H_foo.example.com``
-
-See the genshi `documentation
-<http://genshi.edgewall.org/wiki/Documentation>`_ for examples of
-Genshi syntax.
-
-Examples: Old Genshi Syntax
----------------------------
-
-Genshi's web pages recommend against using this syntax, as it may
-disappear from future releases.
-
-Group Negation
-^^^^^^^^^^^^^^
-
-Templates are also useful for cases where more sophisticated boolean
-operations than those supported by Cfg are needed. For example, the
-template::
-
-    #if "ypbound" in metadata.groups and "workstation" in metadata.groups
-    client is ypbound workstation
-    #end
-    #if "ubuntu" not in metadata.groups and "desktop" in metadata.groups
-    client is a desktop, but not an ubuntu desktop
-    #end
-
-Produces:
-
-.. code-block:: xml
-
-    <Path type="file" name="/bar.conf" owner="root" mode="0644" group="root">client is ypbound workstation
-    client is a desktop, but not an ubuntu desktop
-    </Path>
-
-This flexibility provides the ability to build much more compact and
-succinct definitions of configuration contents than Cfg can.
-
-Troubleshooting
-===============
-
-When developing a template, you can see what the template would
-generate on a client with :ref:`bcfg2-info <server-bcfg2-info>`::
-
-    bcfg2-info buildfile <path> <hostname>
-
-E.g.::
-
-    bcfg2-info buildfile /etc/foo.conf foo.example.com
-
-To generate a file with an altsrc attribute, you can run::
-
-    bcfg2-info buildfile /etc/foo/foo.conf --altsrc=/etc/foo.conf \
-        foo.example.com
-
-Sometimes, it's useful to be able to do more in-depth troubleshooting
-by running the template manually. To do this, run ``bcfg2-info
-debug``, and, once in the Python interpreter, run::
-
-    metadata = self.build_metadata("<hostname>")
-    path = "<relative path to template (see note below)>"
-    
-``path`` should be set to the path to the template file with a leading
-slash, relative to the Bcfg2 specification root. See `Inside of
-Templates`_ for examples.
-
-Then, run::
-    
-    import os, Bcfg2.Options
-    from genshi.template import TemplateLoader, NewTextTemplate
-    name = os.path.dirname(path[path.find('/', 1):])
-    setup = Bcfg2.Options.OptionParser({'repo':
-                                        Bcfg2.Options.SERVER_REPOSITORY})
-    setup.parse('--')
-    template = TemplateLoader().load(setup['repo'] + path, cls=NewTextTemplate)
-    print template.generate(metadata=metadata, path=path, name=name).render()
-
-This gives you more fine-grained control over how your template is
-rendered.
-
-You can also use this approach to render templates that depend on
-:ref:`altsrc <server-plugins-structures-altsrc>` tags by setting
-``path`` to the path to the template, and setting ``name`` to the path
-to the file to be generated, e.g.::
-
-    metadata = self.build_metadata("foo.example.com")
-    path = "/Cfg/etc/sysconfig/network-scripts/ifcfg-template/ifcfg-template.genshi"
-    name = "/etc/sysconfig/network-scripts/ifcfg-bond0"
-
-File permissions
-================
-
-File permissions for entries handled by TGenshi are controlled via the
-use of :ref:`server-info` files. Note that you **cannot** use both a
-Permissions entry and a Path entry to handle the same file.
-
-Error handling
-================
-
-Situations may arise where a templated file cannot be generated due to
-missing or incomplete information.  A TemplateError can be raised to
-force a bind failure and prevent sending an incomplete file to the
-client.  For example, this template::
-
-    {% python
-        from genshi.template import TemplateError
-        grp = None
-        for g in metadata.groups:
-            if g.startswith('ganglia-gmond-'):
-                grp = g
-                break
-        else:
-            raise TemplateError, "Missing group"
-    %}\
-
-will fail to bind if the client is not a member of a group starting with
-"ganglia-gmond-".  The syslogs on the server will contain this message::
-
-    bcfg2-server[5957]: Genshi template error: Missing group
-    bcfg2-server[5957]: Failed to bind entry: Path /etc/ganglia/gmond.conf
-
-indicating the bind failure and message raised with the TemplateError.
-
-FAQs
-====
-
-**Question**
-
-How do I escape the $ (dollar sign) in a TGenshi text template? For
-example, if I want to include SVN (subversion) keywords like $Id$ or
-$HeadURL$ in TGenshi-generated files, or am templating a bourne shell
-(sh/bash) script or Makefile (make).
-
-**Answer**
-
-Use $$ (double dollar sign) to output a literal $ (dollarsign)
-in a TGenshi text template. So instead of $Id$, you'd use
-$$Id$$. See also Genshi tickets `#282: Document $$ escape
-convention <http://genshi.edgewall.org/ticket/282>`_ and
-`#283: Allow for redefinition of template syntax per-file
-<http://genshi.edgewall.org/ticket/283>`_.
-
-Examples
-========
-
-.. toctree::
-   :glob:
-   :maxdepth: 1
-
-   examples/genshi/*
diff --git a/doc/server/plugins/statistics/statistics.txt b/doc/server/plugins/statistics/statistics.txt
deleted file mode 100644
index d16f5a828..000000000
--- a/doc/server/plugins/statistics/statistics.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-plugins-statistics-statistics:
-
-==========
-Statistics
-==========
diff --git a/doc/server/snapshots/index.txt b/doc/server/snapshots/index.txt
deleted file mode 100644
index 13a9fe2c0..000000000
--- a/doc/server/snapshots/index.txt
+++ /dev/null
@@ -1,156 +0,0 @@
-.. -*- mode: rst -*-
-
-.. _server-snapshots-index:
-
-===============
-Bcfg2 Snapshots
-===============
-
-.. versionadded:: 1.0.0
-
-This page describes the Snapshots plugin. This plugin is meant to replace
-the older :ref:`reports-dynamic`. It stores various aspects of a client's
-state when the client checks into the server.
-
-Before you begin
-================
-
-Make sure you have version 0.5 or greater of sqlalchemy.
-
-On CentOS/RHEL 5
-----------------
-
-* Download a tarball of SQLAlchemy.
-* Extract and build the RPM::
-
-      tar xzf SQLAlchemy-0.5.6.tar.gz
-      cd SQLAlchemy-0.5.6
-      python setup.py bdist_rpm
-
-* Copy the RPM in ``SQLAlchemy-0.5.6/dist/`` to your Yum repository,
-  and rebuild the repository using ``createrepo``.
-* Clear the Yum cache::
-
-      sudo yum clean all
-
-* Install SQLAlchemy::
-
-      sudo yum install SQLAlchemy
-
-* Manage the package in Bcfg2 as you would any other package.
-
-Configuration
-=============
-
-* A database location needs to be added to ``bcfg2.conf``. Three drivers
-  are currently supported; mysql, postgres, and sqlite. When using the
-  sqlite driver, only the driver and database lines are required.
-
-  * For MySQL::
-
-        [snapshots]
-        driver = mysql
-        database = snapshots
-        user = snapshots
-        password = snapshots
-        host = dbserver
-
-  * For SQLite::
-
-        [snapshots]
-        driver = sqlite
-        database = /var/lib/bcfg2/var/snapshots.sqlite
-
-* The database needs to be initialized.::
-
-      $ bcfg2-admin snapshots init
-      2009-03-22 21:40:24,683 INFO sqlalchemy.engine.base.Engine.0x...3e2c PRAGMA table_info("connkeyval")
-      PRAGMA table_info("connkeyval")
-      2009-03-22 21:40:24,684 INFO sqlalchemy.engine.base.Engine.0x...3e2c ()
-      ()
-      2009-03-22 21:40:24,686 INFO sqlalchemy.engine.base.Engine.0x...3e2c PRAGMA table_info("package")
-      PRAGMA table_info("package")
-      2009-03-22 21:40:24,687 INFO sqlalchemy.engine.base.Engine.0x...3e2c ()
-      ()
-      .....
-      COMMIT
-
-* The Snapshots plugin needs to be enabled for the bcfg2-server (by adding
-  Snapshots to the plugins line in ``/etc/bcfg2.conf``). Once done,
-  this will cause the the server to store statistics information when
-  clients run.
-
-Using the reports interface
-===========================
-
-All hosts::
-
-    $ bcfg2-admin snapshots reports -a
-
-    ============= ========= ========================================== ============================
-    Client        Correct   Revision                                   Time
-    ============= ========= ========================================== ============================
-    bcfg2client   True      f46ac7773712bd3c3cfb765ae5d2a3b2a37ac9b7   2009-04-23 11:27:54.378941
-    ============= ========= ========================================== ============================
-
-List bad entries for a single host::
-
-    $ bcfg2-admin snapshots reports -b bcfg2client
-    Bad entries:
-     Package:nscd
-     Package:cupsys
-     File:/etc/ldap.conf
-
-List extra entries for a single host::
-
-    $ bcfg2-admin snapshots reports -e bcfg2client
-    Extra entries:
-     Package:python-pyxattr
-     Package:librsync1
-     Package:python-pylibacl
-     Package:gcc-4.2-multilib
-     Package:nxlibs
-     Package:freenx-session-launcher
-     Package:dx-doc
-     Package:dirdiff
-     Package:libhdf4g
-     Package:nxclient
-     Package:freenx-rdp
-     Package:freenx-vnc
-     Package:libxml2-dev
-     Package:mysql-client
-     Package:mysql-client-5.0
-     Package:libxcompext3
-     Package:lib32gomp1
-     Package:dx
-     Package:freenx-media
-     Package:dxsamples
-     Package:gcc-multilib
-     Package:rdiff-backup
-     Package:libdbd-mysql-perl
-     Package:libxcomp3
-     Package:freenx-server
-     Package:smbfs
-     Package:planner
-     Package:nxagent
-     Package:libc6-dev-i386
-     Package:libfltk1.1-dev
-     Package:freenx
-     Package:libdx4
-     Package:libxcompshad3
-     Service:freenx-server
-
-Detailed view of hosts for a particular date::
-
-    $ bcfg2-admin snapshots reports --date 2009 5 30
-    ============= ========= ========================================== ============================
-    Client        Correct   Revision                                   Time
-    ============= ========= ========================================== ============================
-    bcfg2client   False     10c1a12c62c57c0861cc453b8d2640c4839a7357   2009-05-29 10:52:34.701056
-
-TODO/Wishlist
-=============
-
-* Identify per-client changes in correctness over time
-* Detailed view for a particular date
-* Track entry changes over time (glibc updated on these dates to these versions)
diff --git a/doc/unsorted/index.txt b/doc/unsorted/index.txt
index a369ee1b3..74d045990 100644
--- a/doc/unsorted/index.txt
+++ b/doc/unsorted/index.txt
@@ -13,7 +13,6 @@ list below.
 
 .. _TitleIndex: https://trac.mcs.anl.gov/projects/bcfg2/wiki/TitleIndex
 
-* `Plugins/Snapshots`
 * `PrecompiledPackages`
 * `SchemaEvolution`
 * `SecurityDevPlan`