summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorSol Jerome <solj@ices.utexas.edu>2010-08-23 15:56:44 +0000
committerSol Jerome <sol.jerome@gmail.com>2010-08-23 11:01:16 -0500
commit68f2fa13c1d5e7913d8a62f2c712f866b44221cf (patch)
treedfe3b85e4862ff84d59f424a915cb1520c8f1dc9 /doc
parent227fe81eb71dea36d8741effc1109ba066203250 (diff)
downloadbcfg2-68f2fa13c1d5e7913d8a62f2c712f866b44221cf.tar.gz
bcfg2-68f2fa13c1d5e7913d8a62f2c712f866b44221cf.tar.bz2
bcfg2-68f2fa13c1d5e7913d8a62f2c712f866b44221cf.zip
doc: Style fixes
Signed-off-by: Sol Jerome <sol.jerome@gmail.com> git-svn-id: https://svn.mcs.anl.gov/repos/bcfg/trunk/bcfg2@6031 ce84e21b-d406-0410-9b95-82705330c041
Diffstat (limited to 'doc')
-rw-r--r--doc/client/tools/yumng.txt63
-rw-r--r--doc/composable-metadata18
-rw-r--r--doc/getting_started/index.txt4
-rw-r--r--doc/server/plugins/generators/packages.txt5
-rw-r--r--doc/server/plugins/generators/rules.txt2
-rw-r--r--doc/server/plugins/generators/tgenshi/index.txt6
-rw-r--r--doc/server/plugins/probes/producttype.txt4
-rw-r--r--doc/server/reports/dynamic.txt16
8 files changed, 70 insertions, 48 deletions
diff --git a/doc/client/tools/yumng.txt b/doc/client/tools/yumng.txt
index ce1b0a0ad..08fa2d45c 100644
--- a/doc/client/tools/yumng.txt
+++ b/doc/client/tools/yumng.txt
@@ -56,12 +56,14 @@ Features
RPMng Driver Overview
=====================
-The RPMng driver uses a mixture of rpm commands and rpm-python as detailed in the sections below.
+The RPMng driver uses a mixture of rpm commands and rpm-python as detailed
+in the sections below.
rpmtools module
---------------
-The rpmtools module conatins most of the rpm-python code and is imported by RPMng.py and YUMng.py.
+The rpmtools module conatins most of the rpm-python code and is imported
+by RPMng.py and YUMng.py.
RPMng.RefreshPackages()
-----------------------
@@ -145,7 +147,7 @@ configuration file options or as the default driver for RPM packages.
From the command line::
- bcfg2 -n -v -d -D Action,POSIX,Chkconfig,RPMng
+ bcfg2 -n -v -d -D Action,POSIX,Chkconfig,RPMng
This produces quite a bit of output so you may want to redirect the
output to a file for review.
@@ -221,7 +223,7 @@ old RPM driver.
Example - an empty list::
[RPMng]
- installonlypackages =
+ installonlypackages =
Example - The default list::
@@ -261,8 +263,11 @@ The RPMng/YUMng drivers do the following three checks/status:
#. Version
#. rpm verify
-Setting pkg_checks = true (the default) in the client configuration file means that all three checks will be done for all packages.
-Setting pkg_checks = false in the client configuration file means that only the Installed check will be done for all packages.
+Setting pkg_checks = true (the default) in the client configuration file
+means that all three checks will be done for all packages.
+
+Setting pkg_checks = false in the client configuration file means that
+only the Installed check will be done for all packages.
The true/false value can be any combination of upper and lower case.
@@ -279,8 +284,12 @@ The RPMng/YUMng drivers do the following three checks/status:
#. Version
#. rpm verify
-Setting pkg_verify = true (the default) in the client configuration file means that all three checks will be done for all packages as long as pkg_checks = true.
-Setting pkg_verify = false in the client configuration file means that the rpm verify wil not be done for all packages on the client.
+Setting pkg_verify = true (the default) in the client configuration
+file means that all three checks will be done for all packages as long
+as pkg_checks = true.
+
+Setting pkg_verify = false in the client configuration file means that
+the rpm verify wil not be done for all packages on the client.
The true/false value can be any combination of upper and lower case.
@@ -296,7 +305,9 @@ The RPMng/YUMng drivers do the following three checks/status:
#. Version
#. rpm verify
-install_action controls whether or not a package instance will be installed if the installed check fails (i.e. if the package instance isn't installed).
+install_action controls whether or not a package instance will be
+installed if the installed check fails (i.e. if the package instance
+isn't installed).
If install_action = install then the package instance is installed.
If install_action = none then the package instance is not installed.
@@ -313,10 +324,15 @@ The RPMng/YUMng drivers do the following three checks/status:
#. Version
#. rpm verify
-version_fail_action controls whether or not a package instance will be updated if the version check fails (i.e. if the installed package instance isn't the same version as specified in the configuration).
+version_fail_action controls whether or not a package instance will
+be updated if the version check fails (i.e. if the installed package
+instance isn't the same version as specified in the configuration).
+
+If version_fail_action = upgrade then the package instance is upgraded
+(or downgraded).
-If version_fail_action = upgrade then the package instance is upgraded (or down graded).
-If version_fail_action = none then the package instance is not upgraded (or down graded).
+If version_fail_action = none then the package instance is not upgraded
+(or downgraded).
.. note::
#. verion_fail_action must evaluate true for both the client (this option) and the package instance (see the Instance Tag version_fail_action attribute below) for the action to take place.
@@ -338,7 +354,7 @@ If verify_fail_action = reinstall then the package instance is reinstalled.
If verify_fail_action = none then the package instance is not reinstalled.
.. note::
- #. verify_fail_action must evaluate true for both the client (this option) and the package instance (see the Instance Tag verify_fail_action attribute below) for the action to take place.
+ #. verify_fail_action must evaluate true for both the client (this option) and the package instance (see the Instance Tag verify_fail_action attribute below) for the action to take place.
#. yum cannot reinstall packages, so this option is really only relevant to RPMng.
#. RPMng will not attempt to reinstall a package instance if the only failure is an RPM configuration file.
#. RPMng will not attempt to reinstall a package instance if the only failure is an RPM dependency failure.
@@ -347,22 +363,23 @@ Interactive Mode
----------------
Running the client in interactive mode (-I) prompts for the actions to
-be taken as before. Prompts are per package and may apply to multiple
-instances of that package. Each per package prompt will contain a list
+be taken as before. Prompts are per package and may apply to multiple
+instances of that package. Each per package prompt will contain a list
of actions per instance.
-Actions are encoded as
+Actions are encoded as
D - Delete
I - Install
-R - Reinstall
+R - Reinstall
U - Upgrade/Downgrade
-An example is below. The example is from a system that is still using the old Pkgmgr format, so the epoch and arch appear as '*'.::
+An example is below. The example is from a system that is still using
+the old Pkgmgr format, so the epoch and arch appear as '*'.::
Install/Upgrade/delete Package aaa_base instance(s) - R(*:10.2-38.*) (y/N)
Install/Upgrade/delete Package evms instance(s) - R(*:2.5.5-67.*) (y/N)
@@ -434,7 +451,7 @@ Pkgmgr Configuration
Also see the general :ref:`Pkgmgr <server-plugins-generators-pkgmgr>`
and :ref:`server-plugins-structures-altsrc` pages.
-
+
Package Tag (Old style)
^^^^^^^^^^^^^^^^^^^^^^^
@@ -720,7 +737,11 @@ Kernel
Per Instance Ignore
^^^^^^^^^^^^^^^^^^^
-.. note:: In this case a per instance ignore is actually a bad idea as the verify failure is because of multiarch issues where the last package installed wins. So this would be better as a Package level ignore.
+.. note::
+
+ In this case a per instance ignore is actually a bad idea as the
+ verify failure is because of multiarch issues where the last package
+ installed wins. So this would be better as a Package level ignore.
Ignore tag entries only work with the RPMng driver. They do not appear
to be supported in YUMng as of 1.0pre5.
@@ -757,7 +778,7 @@ on the yum man page) is valid.
For RPMng a minimal entry is
.. code-block:: xml
-
+
<Package name="bcfg2" type="rpm" pkg_checks="False" simplefile="bcfg2-0.9.4-0.0pre1.noarch.rpm"/>
verify_fail_action
diff --git a/doc/composable-metadata b/doc/composable-metadata
index 10d55f7c1..82ed8e4ac 100644
--- a/doc/composable-metadata
+++ b/doc/composable-metadata
@@ -1,7 +1,7 @@
-This documents the redesign of the Metadata subsystem.
+This documents the redesign of the Metadata subsystem.
Goals
-* Separate core metadata (groups, etc) functionality from augmentors
+* Separate core metadata (groups, etc) functionality from augmentors
* Enable metadata integration with external data sources
* Make metadata features (group inclusion, categories) usable from
external datasources
@@ -13,7 +13,7 @@ categories, and metadata instance construction. Multiple
MetadataConnectorPlugin instances each contribute additional group
memberships and a set of per-instance key/value pairs. This data is
merged into the client metadata instance by the master
-MetadataPlugin.
+MetadataPlugin.
Use Cases
* Mapping external data into client metadata instances
@@ -31,8 +31,8 @@ API
* Bcfg2.Server.Plugin.MetadataPlugin
** get_initial_metadata(client_name)
** merge_additional_metadata(metadata,
- source,
- group,
+ source,
+ group,
data_dict)
* Bcfg2.Server.Plugin.MetadataConnectorPlugin
** get_additional_metadata(client_metadata)
@@ -41,14 +41,14 @@ Metadata Resolution Control Flow
* B.S.P.MP.resolve_client() -> canonical client name
* B.S.C.C.build_metadata()
** B.S.P.MP.get_initial_metadata() -> partial ClientMetadata inst
-** [B.S.P.MCP.get_additional_metadata()] ->
+** [B.S.P.MCP.get_additional_metadata()] ->
[([group list], {data dictionary})]
** [B.S.P.MP.merge_additional_metadata()]
Implementation Plan (done)
-* Define new plugin classes
-* Split Probe code out to discrete plugin
-* Implement connector support in Core
+* Define new plugin classes
+* Split Probe code out to discrete plugin
+* Implement connector support in Core
* switch callers to Core.build_metadata
* Implement group inheritance/category safety for Connector groups
diff --git a/doc/getting_started/index.txt b/doc/getting_started/index.txt
index 7cd7e8693..fe52807d4 100644
--- a/doc/getting_started/index.txt
+++ b/doc/getting_started/index.txt
@@ -6,10 +6,10 @@
Using Bcfg2
===========
-These are many of the resources available to help new users get started.
+These are many of the resources available to help new users get started.
* For the impatient there is the :ref:`quickstart-index` page.
-* :ref:`gettinghelp` has information when you are troubleshooting or need to ask a question.
+* :ref:`gettinghelp` has information when you are troubleshooting or need to ask a question.
* If you find anything wrong or missing please :ref:`report-a-bug` to let us know.
.. toctree::
diff --git a/doc/server/plugins/generators/packages.txt b/doc/server/plugins/generators/packages.txt
index 323fd97c9..9fc916347 100644
--- a/doc/server/plugins/generators/packages.txt
+++ b/doc/server/plugins/generators/packages.txt
@@ -279,8 +279,9 @@ Generating Client APT/Yum Configurations
.. versionadded:: 1.1.0
-Client repository information can be generated automatically from software sources using
-:doc:`./tgenshi/index` or :doc:`./tcheetah`. A list of source urls are exposed in the client's metadata as
+Client repository information can be generated automatically from
+software sources using :doc:`./tgenshi/index` or :doc:`./tcheetah`.
+A list of source urls are exposed in the client's metadata as
metadata.Packages.sources.
An example :doc:`./tgenshi/index` APT template::
diff --git a/doc/server/plugins/generators/rules.txt b/doc/server/plugins/generators/rules.txt
index bda66bba4..511cfbb47 100644
--- a/doc/server/plugins/generators/rules.txt
+++ b/doc/server/plugins/generators/rules.txt
@@ -131,7 +131,7 @@ Service Tag
| target | Service command for | String |
| | restart, modified | |
| | targets require | |
-| | mode="custom" | |
+| | mode="custom" | |
| | (default: restart) | |
+----------+--------------------------+---------------------------------------+
| type | Driver to use on the | (chkconfig|deb|rc-update|smf|upstart) |
diff --git a/doc/server/plugins/generators/tgenshi/index.txt b/doc/server/plugins/generators/tgenshi/index.txt
index 7eab9dba5..560941cc7 100644
--- a/doc/server/plugins/generators/tgenshi/index.txt
+++ b/doc/server/plugins/generators/tgenshi/index.txt
@@ -139,9 +139,9 @@ Permissions entry and a Path entry to handle the same file.
Error handling
================
-Situations may arrise 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.
+Situations may arrise 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
diff --git a/doc/server/plugins/probes/producttype.txt b/doc/server/plugins/probes/producttype.txt
index 46510c6af..807ecca0e 100644
--- a/doc/server/plugins/probes/producttype.txt
+++ b/doc/server/plugins/probes/producttype.txt
@@ -28,7 +28,7 @@ group has_hardware_emulex_lightpulse.
if [ $os = "Linux" ] ; then
productname=`dmidecode -s system-product-name 2>&1`
case $productname in
- "PowerEdge M600")
+ "PowerEdge M600")
productname="product-bladem600"
;;
"Sun Fire X4100 M2")
@@ -44,7 +44,7 @@ group has_hardware_emulex_lightpulse.
productname="product-unknown"
;;
esac
-
+
# check for emulex lightpulse fiber channel HBA
check_emulex_lightpulse=`lspci -d 10df: | grep -c LightPulse`
if [ $check_emulex_lightpulse -gt 0 ]; then
diff --git a/doc/server/reports/dynamic.txt b/doc/server/reports/dynamic.txt
index 805cfc783..4e34a1c60 100644
--- a/doc/server/reports/dynamic.txt
+++ b/doc/server/reports/dynamic.txt
@@ -23,8 +23,8 @@ Install
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``. Any database supported
-by Django can be used. If you are not using sqlite (the default choice),
-please see the :ref:`alternative-databases` section below. Distributed
+by Django can be used. If you are not using sqlite (the default choice),
+please see the :ref:`alternative-databases` section below. Distributed
environments can share a single remote database for reporting.
Run ``/usr/sbin/bcfg2-admin reports init`` to initialize
@@ -33,7 +33,7 @@ can write to the database.
The recommended statistics plugin is DBStats. To use it, add it to the
**plugins** line in your ``bcfg2.conf``. Alternatively, the Statistics
-plugin can be used in conjunction with a crontab entry to run
+plugin can be used in conjunction with a crontab entry to run
``/usr/sbin/bcfg2-admin reports load_stats``.
Restart the Bcfg2 server. Run a client in dryrun mode in order to get
@@ -93,7 +93,7 @@ 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/``.
+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
@@ -127,7 +127,7 @@ Notes on Alternative Databases
------------------------------
If you choose to use a different database, you'll need to edit
-``/etc/bcfg2.conf``. These fields should be updated in the
+``/etc/bcfg2.conf``. These fields should be updated in the
``statistics`` section:
* database_engine
@@ -169,7 +169,7 @@ 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.
+* 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
@@ -194,7 +194,7 @@ bcfg2-admin reports (command line script)
-----------------------------------------
The bcfg2-admin tool provides management and maintenance capabilities for
-the reporting database. A few useful `Django <http://www.djangoproject.com>`_
+the reporting database. A few useful `Django <http://www.djangoproject.com>`_
commands are provided as well.
* init: Initialize a new database
@@ -208,7 +208,7 @@ Django commands
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* syncdb: Create the tables for any models not installed. Django will
not modify any existing tables.
-* sqlall: Print the sql statements used to create the database. Note:
+* sqlall: Print the sql statements used to create the database. Note:
This does not show the fixture data.
* validate: Validate the database against the current models.