summaryrefslogtreecommitdiffstats
path: root/doc/unsorted
diff options
context:
space:
mode:
authorSol Jerome <solj@ices.utexas.edu>2010-04-10 16:20:14 -0500
committerSol Jerome <solj@ices.utexas.edu>2010-04-10 16:20:14 -0500
commit1999c74bba44c20c37c70d93245e02305a44652a (patch)
treecfd461689888753990d0e3f48c673663f42f3ddd /doc/unsorted
parentb5a201ea431cc3cf33c77364bb0bbf33716401bd (diff)
downloadbcfg2-1999c74bba44c20c37c70d93245e02305a44652a.tar.gz
bcfg2-1999c74bba44c20c37c70d93245e02305a44652a.tar.bz2
bcfg2-1999c74bba44c20c37c70d93245e02305a44652a.zip
doc: Style consistency updates
Signed-off-by: Sol Jerome <solj@ices.utexas.edu>
Diffstat (limited to 'doc/unsorted')
-rw-r--r--doc/unsorted/development_writing_plugins.txt2
-rw-r--r--doc/unsorted/dynamic_groups.txt2
-rw-r--r--doc/unsorted/gentoo.txt24
-rw-r--r--doc/unsorted/howtos.txt6
-rw-r--r--doc/unsorted/mailinglist.txt2
-rw-r--r--doc/unsorted/ssl.txt6
-rw-r--r--doc/unsorted/writing_specification.txt4
7 files changed, 23 insertions, 23 deletions
diff --git a/doc/unsorted/development_writing_plugins.txt b/doc/unsorted/development_writing_plugins.txt
index 89b1af28a..cc0bd7c00 100644
--- a/doc/unsorted/development_writing_plugins.txt
+++ b/doc/unsorted/development_writing_plugins.txt
@@ -66,7 +66,7 @@ If you would like to define your own Metadata plugin (to extend/change functiona
import Bcfg2.Server.Plugins.Metadata
class MyMetadata(Bcfg2.Server.Plugins.Metadata.Metadata):
- '''This class contains data for bcfg2 server metadata'''
+ '''This class contains data for Bcfg2 server metadata'''
__version__ = '$Id$'
__author__ = 'bcfg-dev@mcs.anl.gov'
diff --git a/doc/unsorted/dynamic_groups.txt b/doc/unsorted/dynamic_groups.txt
index e8d2de396..11535dc8b 100644
--- a/doc/unsorted/dynamic_groups.txt
+++ b/doc/unsorted/dynamic_groups.txt
@@ -21,7 +21,7 @@ based on system properties::
group:groupname
-This output is processed by the bcfg2 server, and results in dynamic
+This output is processed by the Bcfg2 server, and results in dynamic
group membership in groupname for the client. See the :ref:`Probes
<server-plugins-probes-index>` page for a more thorough description
of probes.
diff --git a/doc/unsorted/gentoo.txt b/doc/unsorted/gentoo.txt
index 015a19687..4a549210d 100644
--- a/doc/unsorted/gentoo.txt
+++ b/doc/unsorted/gentoo.txt
@@ -7,23 +7,23 @@ Gentoo
======
This document tries to lay out anything Gentoo-specific that you need
-to know in order to use bcfg2. Mostly that has to do with getting it
+to know in order to use Bcfg2. Mostly that has to do with getting it
to cooperate with the various pieces of Portage. Services, all things
-POSIX, and just about anything else that bcfg2 does will work the same
-on Gentoo as on any other distribution. bcfg2 is new on Gentoo; please
+POSIX, and just about anything else that Bcfg2 does will work the same
+on Gentoo as on any other distribution. Bcfg2 is new on Gentoo; please
let the list know if you find errors or omissions.
-Installing bcfg2
+Installing Bcfg2
================
-Early in July 2008, bcfg2 was added to the Gentoo portage tree. So far
+Early in July 2008, Bcfg2 was added to the Gentoo portage tree. So far
it's only keyworded for ~x86, but we hope to see it soon in the amd64 and
x64-solaris ports. If you're using Gentoo on some other architecture, it
should still work provided that you have a reasonably up to date Python;
try adding `app-admin/bcfg2 ~*` to your `/etc/portage/package.keywords`
file.
-If you don’t use portage to install bcfg2, you’ll want to make sure you
+If you don’t use portage to install Bcfg2, you’ll want to make sure you
have all the prerequisites installed first. For a server, you’ll need:
* ``app-admin/gamin`` or ``app-admin/fam``
@@ -106,7 +106,7 @@ conjunction with the `quickpkg` example above:
Configuring Client Machines
===========================
-Set up ``/etc/bcfg2.conf`` the way you would for any other bcfg2 client.
+Set up ``/etc/bcfg2.conf`` the way you would for any other Bcfg2 client.
In ``make.conf``, set *PORTAGE_BINHOST* to point to the URI of
your package repository. You may want to create versions of
@@ -127,7 +127,7 @@ As of this writing (2007/01/31), we’re aware of a number of packages
marked stable in the Gentoo x86 tree which, for one reason or another,
consistently fail to verify cleanly under `equery check`. In some cases
(pam, openldap), files which don’t (ever) exist on the system are
-nonetheless recorded in the package database; in some (python, bcfg2,
+nonetheless recorded in the package database; in some (python, Bcfg2,
ahem), whole classes of files (.pyc and .pyo files) consistently fail
their md5sum checks; and in others, the problem appears to be a
discrepancy in the way that symlinks are created vs. the way they’re
@@ -145,12 +145,12 @@ leading to noise like this::
* 62 out of 66 files good
We can ignore the lines for ``ssh_config`` and ``sshd_config``; those will
-be caught by bcfg2 as registered config files and handled appropriately.
+be caught by Bcfg2 as registered config files and handled appropriately.
-Because bcfg2 relies on the client system’s native package reporting
+Because Bcfg2 relies on the client system’s native package reporting
tool to judge the state of installed packages, complaints like these
about trivial or intractable verification failures can trigger unnecessary
-bundle reinstalls when the bcfg2 client runs. bcfg2 will catch on after a
+bundle reinstalls when the Bcfg2 client runs. Bcfg2 will catch on after a
pass or two that the situation isn’t getting any better with repeated
package installs, stop trying, and list those packages as “bad” in
the client system’s statistics.
@@ -170,7 +170,7 @@ Gentoo as well as some other distros recommend leaving ``/boot`` unmounted
during normal runtime. This can lead to trouble during verification and
package installation, for example when ``/boot/grub/grub.conf`` turns
up missing. The simplest way around this might just be to ensure that
-``/boot`` is mounted whenever you run bcfg2, possibly wrapping bcfg2
+``/boot`` is mounted whenever you run Bcfg2, possibly wrapping Bcfg2
in a script for the purpose. I’ve also thought about adding *Action*
clauses to bundles for grub and our kernel packages, which would mount
``/boot`` before the bundle installs and unmount it afterward, but this
diff --git a/doc/unsorted/howtos.txt b/doc/unsorted/howtos.txt
index bc9c75970..b81f17130 100644
--- a/doc/unsorted/howtos.txt
+++ b/doc/unsorted/howtos.txt
@@ -8,11 +8,11 @@ HOWTOs
Here are several howtos that describe different aspects of Bcfg2 deployment
-* [wiki:Authentication] - a description of the bcfg2 authentication infrastructure
-* AnnotatedExamples - a description of basic bcfg2 specification operations
+* [wiki:Authentication] - a description of the Bcfg2 authentication infrastructure
+* AnnotatedExamples - a description of basic Bcfg2 specification operations
* EncapPackages, EncapReadme, EncapInstall, EncapHowto - building encap packages
* BuildingDebianPackages - How to build debian packages
-* [wiki:Gentoo] - Issues specific to running bcfg2 on Gentoo
+* [wiki:Gentoo] - Issues specific to running Bcfg2 on Gentoo
* [wiki:Plugins/TCheetah TCheetah] - Howto use the TCheetah template plugin
* [wiki:Hostbase] - How to use the Hostbase plugin and web interface
* [wiki:Plugins/Probes Probes] - How to use Probes to gather information from a client machine.
diff --git a/doc/unsorted/mailinglist.txt b/doc/unsorted/mailinglist.txt
index 8f49b2706..72b971d77 100644
--- a/doc/unsorted/mailinglist.txt
+++ b/doc/unsorted/mailinglist.txt
@@ -6,7 +6,7 @@
Mailing List
============
-To subscribe to the mailing list for bcfg2 please visit the `bcfg-dev
+To subscribe to the mailing list for Bcfg2 please visit the `bcfg-dev
mailman page`_
`Searchable archives`_ are available from Gmane. You can also read the
diff --git a/doc/unsorted/ssl.txt b/doc/unsorted/ssl.txt
index 919f7ea71..91b62ca59 100644
--- a/doc/unsorted/ssl.txt
+++ b/doc/unsorted/ssl.txt
@@ -14,7 +14,7 @@ required. A central CA needs to be created, with each server and all
clients getting a signed cert. See [wiki:Authentication] for details.
Setting up keys is accomplished with three settings, each in the
-"`[communication]`" section of bcfg2.conf::
+"`[communication]`" section of ``bcfg2.conf``::
key = /path/to/ssl private key
certificate = /path/to/signed cert for that key
@@ -27,7 +27,7 @@ Python SSL Backport Packaging
Both the Bcfg2 server and client are able to use the in-tree ssl module
included with python 2.6. The client is also able to still use M2Crypto. A
python ssl backport exists for 2.3, 2.4, and 2.5. With this, M2Crypto
-is not needed, and tlslite is no longer included with bcfg2 sources. See
+is not needed, and tlslite is no longer included with Bcfg2 sources. See
[wiki:Authentication] for details.
To build a package of the ssl backport for .deb based distributions
@@ -54,7 +54,7 @@ can be found in the `python-setuptools` package.::
.. note:: Version numbers for the SSL module have changed.
-For complete bcfg2 goodness, you'll also want to package stdeb using stdeb.
+For complete Bcfg2 goodness, you'll also want to package stdeb using stdeb.
The completed debian package can be grabbed from :download:`here
<python-stdeb_0.3-1_all.deb>`, which was generated using the following::
diff --git a/doc/unsorted/writing_specification.txt b/doc/unsorted/writing_specification.txt
index ce7630fde..02f66255b 100644
--- a/doc/unsorted/writing_specification.txt
+++ b/doc/unsorted/writing_specification.txt
@@ -160,7 +160,7 @@ apply to clients who are not a member of said group.
When packages in a bundle are verified by the client toolset, the Paths
included in the same bundle are taken into consideration. That is,
-a package will not fail verification from a bcfg2 perspective if the
+a package will not fail verification from a Bcfg2 perspective if the
package verification only failed because of configuration files that
are defined in the same bundle.
@@ -314,7 +314,7 @@ other groups.
Literal Configuration (Generators)
==================================
-A Generator is a bcfg2 piece of code that is run to generate the literal
+A Generator is a Bcfg2 piece of code that is run to generate the literal
configuration for a host using a combination of the hosts metadata and
abstract configuration.