diff options
| -rw-r--r-- | doc/installation/distributions.txt | 5 | ||||
| -rw-r--r-- | doc/installation/packages.txt | 4 | ||||
| -rw-r--r-- | doc/installation/prerequisites.txt | 40 | ||||
| -rw-r--r-- | doc/introduction/architecture-overview.txt | 3 | ||||
| -rw-r--r-- | doc/introduction/os-support.txt | 2 | ||||
| -rw-r--r-- | doc/server/plugins/generators/packages.txt | 2 | ||||
| -rw-r--r-- | doc/server/plugins/generators/tcheetah.txt | 2 | ||||
| -rw-r--r-- | doc/server/plugins/grouping/grouppatterns.txt | 16 | ||||
| -rw-r--r-- | doc/server/plugins/grouping/ldap.txt | 250 | ||||
| -rw-r--r-- | doc/server/plugins/grouping/metadata.txt | 21 | ||||
| -rw-r--r-- | doc/server/plugins/index.txt | 37 | ||||
| -rw-r--r-- | doc/server/plugins/misc/guppy.txt | 46 | ||||
| -rw-r--r-- | doc/server/plugins/misc/trigger.txt (renamed from doc/server/plugins/trigger.txt) | 7 | ||||
| -rw-r--r-- | doc/server/plugins/probes/index.txt | 42 | ||||
| -rw-r--r-- | doc/server/plugins/probes/ohai.txt | 36 | ||||
| -rw-r--r-- | doc/server/plugins/structures/altsrc.txt | 8 | ||||
| -rw-r--r-- | doc/server/plugins/structures/base.txt | 2 | ||||
| -rw-r--r-- | doc/server/plugins/structures/bundler/index.txt | 29 | ||||
| -rw-r--r-- | src/lib/Client/Tools/Chkconfig.py | 4 |
19 files changed, 431 insertions, 125 deletions
diff --git a/doc/installation/distributions.txt b/doc/installation/distributions.txt index a4ce9fb5d..383943e9f 100644 --- a/doc/installation/distributions.txt +++ b/doc/installation/distributions.txt @@ -93,8 +93,8 @@ Clone the git source:: git clone git://git.mcs.anl.gov/bcfg2.git Change to the osx directory and type make. Your new package should be -located at bcfg2-$VERSION.pkg (where $VERSION is that which is specified -in setup.py). +located at ``bcfg2-$VERSION.pkg`` (where ``$VERSION`` is that which is +specified in ``setup.py``). RHEL / Centos / Scientific Linux ================================ @@ -121,7 +121,6 @@ Install the bcfg2-server and bcfg2 RPMs:: .. _CentOS: http://www.centos.org/ .. _Scientific Linux: http://www.scientificlinux.org/ .. _EPEL: http://fedoraproject.org/wiki/EPEL -.. _RPMForge: https://rpmrepo.org/RPMforge Ubuntu ====== diff --git a/doc/installation/packages.txt b/doc/installation/packages.txt index b175d2625..6a9f6ed1a 100644 --- a/doc/installation/packages.txt +++ b/doc/installation/packages.txt @@ -43,11 +43,11 @@ Building RPM packages with ``rpmbuild`` While you can go about building all these things from source, this how to will try and meet the dependencies using packages from EPEL_. -The *el5* package should be compatible with CentOS 5.x. +The *el5* and the *el6* package should be compatible with CentOS 5.x. * Installation of the EPEL_ repository package :: - [root@centos ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm + [root@centos ~]# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-6.noarch.rpm * Now you can install the rest of the prerequisites :: diff --git a/doc/installation/prerequisites.txt b/doc/installation/prerequisites.txt index 758ee4a21..c86e86774 100644 --- a/doc/installation/prerequisites.txt +++ b/doc/installation/prerequisites.txt @@ -14,25 +14,25 @@ what software is needed on the client and server side. Bcfg2 Client ------------ -+----------------------------+---------------+--------------------------------+ -| Software | Version | Requires | -+============================+===============+================================+ -| libxml2 (if lxml is used) | Any | | -+----------------------------+---------------+--------------------------------+ -| libxslt (if lxml is used) | Any | libxml2 | -+----------------------------+---------------+--------------------------------+ -| python | >= 2.3 [#f1]_ | | -+----------------------------+---------------+--------------------------------+ -| lxml or elementtree [#f2]_ | Any | lxml: libxml2, libxslt, python | -+----------------------------+---------------+--------------------------------+ -| python-apt [#f3]_ | Any | python | -+----------------------------+---------------+--------------------------------+ -| debsums (if APT tool | Any | | -| driver is used) | | | -+----------------------------+---------------+--------------------------------+ - - -.. [#f1] python 2.5 works with elementtree. ++----------------------------+------------------------+--------------------------------+ +| Software | Version | Requires | ++============================+========================+================================+ +| libxml2 (if lxml is used) | Any | | ++----------------------------+------------------------+--------------------------------+ +| libxslt (if lxml is used) | Any | libxml2 | ++----------------------------+------------------------+--------------------------------+ +| python | 2.3-2.4, 2.5-2.7 [#f1] | | ++----------------------------+------------------------+--------------------------------+ +| lxml or elementtree [#f2]_ | Any | lxml: libxml2, libxslt, python | ++----------------------------+------------------------+--------------------------------+ +| python-apt [#f3]_ | Any | python | ++----------------------------+------------------------+--------------------------------+ +| debsums (if APT tool | Any | | +| driver is used) | | | ++----------------------------+------------------------+--------------------------------+ + + +.. [#f1] python 2.5 and later works with elementtree. .. [#f2] elementtree is included in python 2.5 and later. .. [#f3] python-apt is only required on platforms that use apt, such as Debian and Ubuntu. @@ -46,7 +46,7 @@ Bcfg2 Server +----------------------------+----------+--------------------------------+ | libxslt | Any | libxml2 | +----------------------------+----------+--------------------------------+ -| python | 2.2-2.5 | | +| python | 2.2-2.7 | | +----------------------------+----------+--------------------------------+ | lxml | 0.9+ | lxml: libxml2, libxslt, python | +----------------------------+----------+--------------------------------+ diff --git a/doc/introduction/architecture-overview.txt b/doc/introduction/architecture-overview.txt index 55bf4e557..0d3562be4 100644 --- a/doc/introduction/architecture-overview.txt +++ b/doc/introduction/architecture-overview.txt @@ -24,7 +24,8 @@ The role of the Bcfg2 server is rendering a client-specific target configuration description from a global specification. The specification consists of a directory structure containing data for a variety of server plugins. The Bcfg2 server has a plugin interface that can be used to -interpret the configuration specification. +interpret the configuration specification. Read on for more information +about :ref:`server-index`. Client ------ diff --git a/doc/introduction/os-support.txt b/doc/introduction/os-support.txt index 3e27019f2..881fdc6dd 100644 --- a/doc/introduction/os-support.txt +++ b/doc/introduction/os-support.txt @@ -40,7 +40,7 @@ Bcfg2 is fairly portable. It has been successfully run on: Bcfg2 should run on any POSIX compatible operating system, however direct support for an operating system's package and service formats -are limited by the currently available :ref:`client-tools-index` +are limited by the currently available :ref:`client-tools` (new client tools are pretty easy to add). Check the :ref:`FAQ <faq-general>` for a more exact list of platforms on which Bcfg2 works`. diff --git a/doc/server/plugins/generators/packages.txt b/doc/server/plugins/generators/packages.txt index 9fc916347..774de44ee 100644 --- a/doc/server/plugins/generators/packages.txt +++ b/doc/server/plugins/generators/packages.txt @@ -145,7 +145,7 @@ like this: default. You will notice that the default behavior for apt is to add Recommended packages as dependencies. You can configure the Packages plugin to add recommended packages by adding - the following: + the following line immediately following the URL: .. versionadded:: 1.1.0 diff --git a/doc/server/plugins/generators/tcheetah.txt b/doc/server/plugins/generators/tcheetah.txt index 8077d313e..f2ca6c87c 100644 --- a/doc/server/plugins/generators/tcheetah.txt +++ b/doc/server/plugins/generators/tcheetah.txt @@ -48,7 +48,7 @@ self.metadata is an instance of the class ClientMetadata and documented :ref:`here <server-plugins-grouping-metadata-clientmetadata>`. self.metadata.Properties.data -======================== +============================= Properties.data is a python `ElementTree <http://codespeak.net/lxml/>`_ object, loaded from the data in ``/var/lib/bcfg2/Properties/<properties diff --git a/doc/server/plugins/grouping/grouppatterns.txt b/doc/server/plugins/grouping/grouppatterns.txt index 384b00c5e..39c632f82 100644 --- a/doc/server/plugins/grouping/grouppatterns.txt +++ b/doc/server/plugins/grouping/grouppatterns.txt @@ -8,8 +8,12 @@ GroupPatterns The GroupPatterns plugin is a connector that can assign clients group membership pased on patterns in client hostnames. Two basic -methods are supported: regular expressions (NamePatterns) and ranges -(NameRange). Hosts that match the specification are placed in the group +methods are supported: + +- regular expressions (NamePatterns) +- ranges (NameRange) + +Hosts that match the specification are placed in the group or groups specified by the pattern. Setup @@ -26,13 +30,13 @@ NamePatterns use regular expressions to match client hostnames. All matching clients are placed in the resulting groups. NamePatterns also have the ability to use regular expression matched groups to dynamically create group names. The first two examples below are NamePatterns. The -first adds client hostname to both groups gp-test1 and gp-test2. The +first adds client hostname to both groups *gp-test1* and *gp-test2*. The second matches the hostname as a group and places the client in a group -called group-<hostname>. +called *group-<hostname>*. NameRange patterns allow the use of the application of numeric ranges -to host names. The final pattern below matches any of node1-node32 and -places them all into the rack1 group. Dynamically generated group names +to host names. The final pattern below matches any of *node1-node32* and +places them all into the *rack1* group. Dynamically generated group names are not supported with NameRange. Examples diff --git a/doc/server/plugins/grouping/ldap.txt b/doc/server/plugins/grouping/ldap.txt new file mode 100644 index 000000000..90590a272 --- /dev/null +++ b/doc/server/plugins/grouping/ldap.txt @@ -0,0 +1,250 @@ +.. -*- mode: rst -*- + +.. _server-plugins-grouping-ldap: + +==== +Ldap +==== + +.. warning:: + This plugin is considered experimental and has known issues (see below). + +Purpose +------- + +This plugin makes it possible to fetch data from an LDAP directory, process it +and attach it to your metadata. + +Installation +------------ + +__ http://www.python-ldap.org/ + +First, you need to install the `python-ldap library`__. On debian-based systems this is +accomplished by:: + + aptitude install python-ldap + +To enable the plugin, add "Ldap" to the plugins line in your ``bcfg2.conf``. +Then add a new directory called "Ldap" to the root of your Bcfg2 repository and +define your queries in a file called ``config.py`` using the information in the +next section. + +Configuration +------------- + +As processing LDAP search results can get pretty complex, the configuration has +to be written in Python. + +Here is a minimal example to get you started:: + + from Bcfg2.Server.Plugins.Ldap import LdapConnection, LdapQuery, LdapSubQuery, register_query + + conn_default = LdapConnection() + conn_default.binddn = "uid=example,ou=People,dc=example,dc=com" + conn_default.bindpw = "foobat" + + @register_query + class ExampleQuery(LdapQuery): + name = "example" + base = "ou=People,dc=example,dc=com" + scope = "one" + attrs = ["cn", "uid"] + connection = conn_default + + def prepare_query(self, metadata): + self.filter = "(personalServer=" + metadata.hostname + ")" + + def process_result(self, metadata): + if not self.result: + admin_uid = None + admin_name = "This server has no admin." + return { + "admin_uid" : self.result[0][1]["uid"], + "admin_name" : self.result[0][1]["cn"] + } + +The first line provides three classes for dealing with connections and queries +(details below) and a decorator function for registering your queries with the plugin. + +In this example our LDAP directory has a number of user objects in it. Each of those +may have a personal server they administer. Whenever metadata for this machine is being +generated by the Bcfg2 server, the UID and name of the admin are retrieved from LDAP. + +In your bundles and config templates, you can access this data via the metadata object:: + + ${metadata.Ldap["example"]["admin_name"]} + +Class reference +--------------- + +LdapConnection +++++++++++++++ + +.. class:: LdapConnection + + This class represents an LDAP connection. Every query must be associated with exactly + one connection. + +.. attribute:: LdapConnection.binddn + + DN used to authenticate against LDAP (required). + +.. attribute:: LdapConnection.bindpw + + Password for the previously mentioned **binddn** (required). + +.. attribute:: LdapConnection.host + + Hostname of host running the LDAP server (defaults to "localhost"). + +.. attribute:: LdapConnection.port + + Port where LDAP server is listening (defaults to 389). + +You may pass any of these attributes as keyword arguments when creating the connection object. + +LdapQuery ++++++++++ + +.. class:: LdapQuery + + This class defines a single query that may adapt itself depending on the current metadata. + +.. attribute:: LdapQuery.attrs + + Can be used to retrieve only a certain subset of attributes. May either be a list of + strings (attribute names) or ``None``, meaning all attributes (defaults to ``None``). + +.. attribute:: LdapQuery.base + + This is the search base. Only LDAP entries below this DN will be included in your + search results (required). + +.. attribute:: LdapQuery.connection + + Set this to an instance of the LdapConnection class (required). + +.. attribute:: LdapQuery.filter + + LDAP search filter used to narrow down search results (defaults to ``(objectClass=*)``). + +.. attribute:: LdapQuery.name + + This will be used as the dictionary key that provides access to the query results from + the metadata object (``metadata.Ldap["NAMEGOESHERE"]``) (required). + +.. attribute:: LdapQuery.scope + + Set this to one of "base", "one" or "sub" to specify LDAP search depth (defaults to "sub"). + +.. method:: LdapQuery.is_applicable(self, metadata) + + You can override this method to indicate whether this query makes sense for a given + set of metadata (e.g. you need a query only for a certain bundle or group). + + (defaults to returning True) + +.. method:: LdapQuery.prepare_query(self, metadata) + + Override this method to alter the query prior to execution. This is useful if your filter + depends on the current metadata, e.g.:: + + self.filter = "(cn=" + metadata.hostname + ")" + + (defaults to doing nothing) + +.. method:: LdapQuery.process_result(self, metadata) + + You will probably override this method in every query to reformat the results from LDAP. + The raw result is stored in ``self.result``, you must return the altered data. Note that LDAP + search results are presented in this structure:: + + ( + ("DN of first entry returned", + { + "firstAttribute" : 1, + "secondAttribute" : 2, + } + ), + ("DN of second entry returned", + { + "firstAttribute" : 1, + "secondAttribute" : 2, + } + ), + ) + + Therefore, to return just the value of the firstAttribute of the second object returned, + you'd write:: + + return self.result[1][1][0] + + (defaults to returning ``self.result`` unaltered) + +LdapSubQuery +++++++++++++ + +.. class:: LdapSubQuery + + Sometimes you need more than one query to obtain the data you need (e.g. use the first + query to return all websites running on metadata.hostname and another query to find all + customers that should have access to those sites). + + LdapSubQueries are the same as LdapQueries, except for that the methods + + * ``get_result()`` + * ``prepare_query()`` + * ``process_result()`` + + allow any additional keyword arguments that may contain additional data as needed. Note + that ``get_result()`` will call ``prepare_query()`` and ``process_result()`` for you, + so you shouldn't ever need to invoke these yourself, just override them. + +Here is another example that uses LdapSubQuery:: + + class WebSitesQuery(LdapSubQuery): + name = "web_sites" + filter = "(objectClass=webHostingSite)" + attrs = ["dc"] + connection = conn_default + + def prepare_query(self, metadata, base_dn): + self.base = base_dn + + def process_result(self, metadata): + [...] # build sites dict from returned dc attributes + return sites + + @register_query + class WebPackagesQuery(LdapQuery): + name = "web_packages" + base = "dc=example,dc=com" + attrs = ["customerId"] + connection = conn_default + + def prepare_query(self, metadata): + self.filter = "(&(objectClass=webHostingPackage)(cn:dn:=" + metadata.hostname + "))" + + def process_result(self, metadata): + customers = {} + for customer in self.result: + dn = customer[0] + cid = customer[1]["customerId"][0] + customers[cid]["sites"] = WebSitesQuery().get_result(metadata, base_dn = dn) + return customers + +This example assumes that we have a number of webhosting packages that contain various +sites. We need a first query ("web_packages") to get a list of the packages our customers +have and another query for each of those to find out what sites are contained in each +package. The magic happens in the second class where ``WebSitesQuery.get_result()`` is +called with the additional ``base_dn`` parameter that allows our LdapSubQuery to only +search below that DN. + +.. warning:: + Do NOT apply the ``register_query`` decorator to LdapSubQueries. + +Known Issues +------------ + +* At this point there is no support for SSL/TLS. diff --git a/doc/server/plugins/grouping/metadata.txt b/doc/server/plugins/grouping/metadata.txt index 071d4239d..f215e6cc5 100644 --- a/doc/server/plugins/grouping/metadata.txt +++ b/doc/server/plugins/grouping/metadata.txt @@ -16,11 +16,11 @@ and clients' memberships are reflected in the ``Metadata/groups.xml`` and Usage of Groups in Metadata =========================== -Clients are assigned membership of groups in the Metadata -descriptions. Clients can be directly assigned to 'profile' or 'public' -groups. Client membership of all other groups is by those groups being +Clients are assigned membership of groups in the Metadata descriptions. +Clients can be directly assigned to *'profile'* or *'public'* groups. +Client membership of all other groups is by those groups being associated with the profile or public groups. This file can be indirectly -modified from clients through use of the -p flag to bcfg2. +modified from clients through use of the ``-p`` flag to ``bcfg2``. Clients are associated with profile groups in ``Metadata/clients.xml`` as shown below. @@ -29,7 +29,7 @@ Metadata/clients.xml ==================== The ``Metadata/clients.xml`` file contains the mappings of Profile Groups -to clients. The file is just a series of <Client /> tags, each of which +to clients. The file is just a series of *<Client />* tags, each of which describe one host. A sample file is below: .. code-block:: xml @@ -122,11 +122,11 @@ definitions. Here's a simple ``Metadata/groups.xml`` file: <Bundle name='mail-server'/> <Bundle name='mailman-server'/> <Group name='apache-server'/> - <Group name='rhel-as-4-x86'/> + <Group name='rhel-as-5-x86'/> <Group name='nfs-client'/> <Group name='server'/> </Group> - <Group name='rhel-as-4-x86'> + <Group name='rhel-as-5-x86'> <Group name='rhel'/> </Group> <Group name='apache-server'/> @@ -139,7 +139,7 @@ definitions. Here's a simple ``Metadata/groups.xml`` file: Nested/chained groups definitions are conjunctive (logical and). For instance, in the above example, a client associated with the Profile Group ``mail-server`` is also a member of the ``apache-server``, -``rhel-as-4-x86``, ``nfs-client``, ``server`` and ``rhel`` groups. +``rhel-as-5-x86``, ``nfs-client``, ``server``, and ``rhel`` groups. Groups describe clients in terms for abstract, disjoint aspects. Groups can be combined to form complex descriptions of clients that use @@ -231,8 +231,9 @@ is fully documented :ref:`here <server-plugins-probes-index>`. ClientMetadata ============== -A special client metadata class is available to the TGenshi and TCheetah -plugins. +A special client metadata class is available to the +:ref:`TGenshi <server-plugins-generators-tgenshi-index>` and +:ref:`TCheetah <server-plugins-generators-tcheetah>` plugins. +----------------------+------------------------------------------------+-------------------+ | Attribute | Description | Value | diff --git a/doc/server/plugins/index.txt b/doc/server/plugins/index.txt index 61f91da86..8ef3d5af3 100644 --- a/doc/server/plugins/index.txt +++ b/doc/server/plugins/index.txt @@ -11,8 +11,12 @@ perform one of several tasks: #. 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:`server-plugins-probes-index`. -#. Automating administrative tasks (e.g. :ref:`server-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-index`. +#. Automating administrative tasks + (e.g. :ref:`server-plugins-generators-sshbase` which automates ssh + key management) #. Generating client per-entry installation decision-lists Enabling Plugins @@ -24,17 +28,16 @@ the *plugins* line in ``bcfg2.conf``. Default Plugins =============== -The `Bcfg2 repository`_ has the default -plugin list currently distributed with Bcfg2: -http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins. +The `Bcfg2 repository`_ contains the all plugins currently distributed +with Bcfg2. -.. _Bcfg2 repository: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/bcfg2/src/lib/Server/Plugins. +.. _Bcfg2 repository: http://trac.mcs.anl.gov/projects/bcfg2/browser/src/lib/Server/Plugins Metadata (Grouping) ------------------- .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :glob: grouping/* @@ -46,7 +49,7 @@ Abstract Configuration (Structures) ----------------------------------- .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :glob: structures/bundler/index @@ -59,7 +62,7 @@ Literal Configuration (Generators) ---------------------------------- .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :glob: generators/tgenshi/index @@ -72,7 +75,7 @@ Connector Plugins ----------------- .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :glob: connectors/* @@ -81,7 +84,7 @@ Statistics Plugins ------------------ .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :glob: statistics/* @@ -93,11 +96,20 @@ Version Plugins --------------- .. toctree:: - :maxdepth: 2 + :maxdepth: 1 :glob: version/* +Miscellaneous Plugins +--------------------- + +.. toctree:: + :maxdepth: 1 + :glob: + + misc/* + Plugin Roles (in 1.0) ===================== @@ -112,4 +124,3 @@ More details can be found in :ref:`server-plugins-plugin-roles` plugin-roles probes/index - trigger diff --git a/doc/server/plugins/misc/guppy.txt b/doc/server/plugins/misc/guppy.txt new file mode 100644 index 000000000..8307218e3 --- /dev/null +++ b/doc/server/plugins/misc/guppy.txt @@ -0,0 +1,46 @@ +.. -*- mode: rst -*- + +.. _server-plugins-misc-guppy: + +===== +Guppy +===== + +This plugin is used to trace memory leaks within the bcfg2-server +process using Guppy_. By default the remote debugger is started +when this plugin is enabled. The debugger can be disabled in a running +process using ``bcfg2-admin xcmd Guppy.Disable`` and enabled using +``bcfg2-admin xcmd Guppy.Enable``. + +.. _Guppy: http://pypi.python.org/pypi/guppy/0.1.8 + +Setup +===== + +- Install the Guppy_ package first. + +- Add *Guppy* to the **plugins** line in ``bcfg2.conf``. + +Use cases +========= + +To attach the console run:: + + python -c "from guppy import hpy;hpy().monitor()" + +Example +======= + +.. code-block:: sh + + # python -c "from guppy import hpy;hpy().monitor()" + <Monitor> + *** Connection 1 opened *** + <Monitor> lc + CID PID ARGV + 1 25063 ['/usr/sbin/bcfg2-server', '-D', '/var/run/bcfg2-server.pid'] + <Monitor> sc 1 + Remote connection 1. To return to Monitor, type <Ctrl-C> or .<RETURN> + <Annex> int + Remote interactive console. To return to Annex, type '-'. + >>> hp.heap() diff --git a/doc/server/plugins/trigger.txt b/doc/server/plugins/misc/trigger.txt index 853b524e4..7547f2fdd 100644 --- a/doc/server/plugins/trigger.txt +++ b/doc/server/plugins/misc/trigger.txt @@ -1,6 +1,6 @@ .. -*- mode: rst -*- -.. _server-plugins-trigger: +.. _server-plugins-misc-trigger: ======= Trigger @@ -12,7 +12,7 @@ clients are configured. Setup ===== -First, add Trigger to the **plugins** line in bcfg2.conf. Then do the +First, add Trigger to the **plugins** line in ``bcfg2.conf``. Then do the following:: mkdir /var/lib/bcfg2/Trigger @@ -22,7 +22,8 @@ following:: Use cases ========= -#. Completing network builds (ie resetting from the build target to the boot pxe target) +#. Completing network builds (ie resetting from the build target to the + boot PXE target) #. Integration with external systems Trigger Arguments diff --git a/doc/server/plugins/probes/index.txt b/doc/server/plugins/probes/index.txt index 87fd2ba2c..33ec6f444 100644 --- a/doc/server/plugins/probes/index.txt +++ b/doc/server/plugins/probes/index.txt @@ -90,7 +90,8 @@ script's output as seen above. Note that we had to wrap the output in an `int()` call; the script output is treated as a string, so it needs to be converted before it can be tested numerically. -With all of these pieces in place, the following series of events will happen when the client is run: +With all of these pieces in place, the following series of events will +happen when the client is run: #. Client runs #. Server hands down our ``scratchlocal`` probe script @@ -120,6 +121,10 @@ specific one is used. Only one instance of a probe is served to a given client, so if a host-specific version and generic version apply, only the client-specific one will be used. +If you want to to detect information about the client operating system, +the :ref:`server-plugins-probes-ohai` plugin can help. + + Other examples ============== @@ -134,36 +139,7 @@ Other examples producttype serial-console-speed -=========== -Ohai probes -=========== - -.. _Ohai: http://wiki.opscode.com/display/ohai/Home -.. _Ohai-Install: http://wiki.opscode.com/display/ohai/Installation - -The `Ohai`_ plugin is used to detect information about the client -operating system. The data is reported back to the server using JSON. - -Client prerequisites -==================== - -On the client, you need to install `Ohai`_. See `Ohai-Install`_ for more -information. - -Server prerequisites -==================== - -If you have python 2.6 or later installed, you can continue on to -:ref:`ohai-setup`. Otherwise, you will need to install the -python-simplejson module found packaged in most distributions. - -.. _ohai-setup: - -Setup -===== +.. toctree:: + :hidden: -To enable the Ohai plugin, you need to first create an ``Ohai`` directory -in your Bcfg2 repository (e.g. ``/var/lib/bcfg2/Ohai``). You then need -to add **Ohai** to the plugins line in ``bcfg2.conf``. Once this is done, -restart the server and start a client run. You will have the JSON output -from the client in the ``Ohai`` directory you created previously. + ohai diff --git a/doc/server/plugins/probes/ohai.txt b/doc/server/plugins/probes/ohai.txt new file mode 100644 index 000000000..f44a64c58 --- /dev/null +++ b/doc/server/plugins/probes/ohai.txt @@ -0,0 +1,36 @@ +.. -*- mode: rst -*- + +.. _server-plugins-probes-ohai: + +Ohai +==== + +.. _Ohai: http://wiki.opscode.com/display/ohai/Home +.. _Ohai-Install: http://wiki.opscode.com/display/ohai/Installation + +The `Ohai`_ plugin is used to detect information about the client +operating system. The data is reported back to the server using JSON. + +Client prerequisites +-------------------- + +On the client, you need to install `Ohai`_. See `Ohai-Install`_ for more +information. + +Server prerequisites +-------------------- + +If you have python 2.6 or later installed, you can continue on to +:ref:`ohai-setup`. Otherwise, you will need to install the +python-simplejson module found packaged in most distributions. + +.. _ohai-setup: + +Setup +----- + +To enable the Ohai plugin, you need to first create an ``Ohai`` directory +in your Bcfg2 repository (e.g. ``/var/lib/bcfg2/Ohai``). You then need +to add **Ohai** to the plugins line in ``bcfg2.conf``. Once this is done, +restart the server and start a client run. You will have the JSON output +from the client in the ``Ohai`` directory you created previously. diff --git a/doc/server/plugins/structures/altsrc.txt b/doc/server/plugins/structures/altsrc.txt index fd7978efb..bed170b9c 100644 --- a/doc/server/plugins/structures/altsrc.txt +++ b/doc/server/plugins/structures/altsrc.txt @@ -2,13 +2,13 @@ .. _server-plugins-structures-altsrc: -=========================== -Fun and Profit using altsrc -=========================== +====== +altsrc +====== .. versionadded:: 0.9.5 -Altsrc is a generic, bcfg2-server-side mechanism for performing +Altsrc is a generic, Bcfg2 server-side mechanism for performing configuration entry name remapping for the purpose of data binding. Altsrc can be used as a parameter for any entry type, and can be used in any structure, including Bundler and Base. diff --git a/doc/server/plugins/structures/base.txt b/doc/server/plugins/structures/base.txt index 47fba8334..66d8062e1 100644 --- a/doc/server/plugins/structures/base.txt +++ b/doc/server/plugins/structures/base.txt @@ -73,4 +73,4 @@ various linux distributions. In this case, you may want to manage the ``/etc/hosts`` file using Base instead of Bundler since you will not have to include any Bundles in your Metadata. However, you could alternatively have a base 'linux' group that all the clients inherit which includes a -'linux' Bundle with the ``/etc/hosts`` configuration entry. +*linux* Bundle with the ``/etc/hosts`` configuration entry. diff --git a/doc/server/plugins/structures/bundler/index.txt b/doc/server/plugins/structures/bundler/index.txt index da49b299e..e5682ac00 100644 --- a/doc/server/plugins/structures/bundler/index.txt +++ b/doc/server/plugins/structures/bundler/index.txt @@ -44,7 +44,7 @@ The following is an annotated copy of a bundle: <Package name='openssh-askpass'/> <Service name='sshd'/> <Group name='fedora' > - <Group name='fc4' negate='true'> + <Group name='fc14' negate='true'> <Package name='openssh-clients'/> </Group> <Package name='openssh-server'/> @@ -60,7 +60,7 @@ In this bundle, most of the entries are common to all systems. Clients in group **deb** get one extra package and service, while clients in group **rpm** get two extra packages and an extra service. In addition, clients in group **fedora** *and* group **rpm** get one extra package entries, -unless they are not in the **fc4** group, in which case, they get an +unless they are not in the **fc14** group, in which case, they get an extra package. Notice that this file doesn't describe which versions of these entries that clients should get, only that they should get them. (Admittedly, this example is slightly contrived, but demonstrates @@ -220,28 +220,9 @@ fact be any python statement. Other examples ============== -Some simple examples of Bundles can be found in the example repository -at the locations in the following table: - -+--------------+---------------------+ -| Bundle Name | Description | -+==============+=====================+ -| `atxml`_ | At bundle | -+--------------+---------------------+ -| `bcfgxml`_ | Bcfg2 client bundle | -+--------------+---------------------+ -| `ntpxml`_ | NTP bundle | -+--------------+---------------------+ -| `sshxml`_ | OpenSSH bundle | -+--------------+---------------------+ -| `syslogxml`_ | syslog bundle | -+--------------+---------------------+ - -.. _atxml: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/repository/Bundler/at.xml -.. _bcfgxml: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/repository/Bundler/bcfg.xml -.. _ntpxml: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/repository/Bundler/ntp.xml -.. _sshxml: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/repository/Bundler/ssh.xml -.. _syslogxml: http://trac.mcs.anl.gov/projects/bcfg2/browser/trunk/repository/Bundler/syslog.xml +Some simple examples of Bundles can be found in the `Bcfg2 example repository`_. + +.. _Bcfg2 example repository: https://github.com/solj/bcfg2-repo In addition to the example repository, the following is a list of some more complex example Bundles. diff --git a/src/lib/Client/Tools/Chkconfig.py b/src/lib/Client/Tools/Chkconfig.py index b7227ec3d..bf2a2c1e1 100644 --- a/src/lib/Client/Tools/Chkconfig.py +++ b/src/lib/Client/Tools/Chkconfig.py @@ -60,8 +60,8 @@ class Chkconfig(Bcfg2.Client.Tools.SvcTool): if not(self.setup.get('dryrun')) and needs_modification: self.cmd.run('/sbin/service %s %s' % (entry.get('name'), command)) - pstatus = self.cmd.run('/sbin/service %s status' % \ - entry.get('name'))[0] + # service was modified, so it failed + pstatus = False # chkconfig/init.d service if entry.get('status') == 'on': |