added Client tag to StructFile; made PropertyFile inherit from StructFile

2 files changed, 40 insertions, 21 deletions

diff --git a/doc/server/plugins/connectors/properties.txt b/doc/server/plugins/connectors/properties.txt
index ef408916e..9fb0dba87 100644
--- a/doc/server/plugins/connectors/properties.txt
+++ b/doc/server/plugins/connectors/properties.txt
@@ -41,9 +41,20 @@ templates as ``metadata.Properties[<filename>]``. The
 data attribute is an LXML element object. (Documented
 `here <http://codespeak.net/lxml/tutorial.html#the-element-class>`_)
 
-Currently, no access methods are defined for this data, but as we
-formulate common use cases, we will add them to the !PropertyFile class
-as methods. This will simplify templates.
+Currently, only one access method is defined for this data, ``Match``.
+``Match`` parses the Group and Client tags in the file and returns a
+list of elements that apply to the client described by a set of
+metadata.  (See :ref:`server-plugins-structures-bundler-index` for
+more details on how Group and Client tags are parsed.)  For instance::
+
+    {% python
+    ntp_servers = [el.text
+                   for el in metadata.Properties['ntp.xml'].Match(metadata):
+                   if el.tag == "Server"]
+    %}
+
+As we formulate more common use cases, we will add them to the
+!PropertyFile class as methods. This will simplify templates.
 
 Accessing Properties contents from TGenshi
 ==========================================
diff --git a/doc/server/plugins/structures/bundler/index.txt b/doc/server/plugins/structures/bundler/index.txt
index 0d0054a2c..c84d6cdbe 100644
--- a/doc/server/plugins/structures/bundler/index.txt
+++ b/doc/server/plugins/structures/bundler/index.txt
@@ -16,14 +16,15 @@ entries. For example, a bundle could say that the configuration file
 describe the particular version of ``/etc/passwd`` that a given client
 will receive.
 
-Groups can be used inside of bundles to differentiate which entries
-particular clients will recieve; this is useful for the case where
-entries are named differently across systems; for example, one linux
-distro may have a package called openssh while another uses the name
-ssh. Configuration entries nested inside of Group elements only apply
-to clients who are a member of those groups; multiple nested groups must
-all apply. Also, groups may be negated; entries included in such groups
-will only apply to clients who are not a member of said group.
+Group and Client tags can be used inside of bundles to differentiate
+which entries particular clients will recieve; this is useful for the
+case where entries are named differently across systems; for example,
+one linux distro may have a package called openssh while another uses
+the name ssh. Configuration entries nested inside of Group elements
+only apply to clients who are a member of those groups; multiple
+nested groups must all apply. Also, groups may be negated; entries
+included in such groups will only apply to clients who are not a
+member of said group.  The same applies to Client elements.
 
 The following is an annotated copy of a bundle:
 
@@ -54,20 +55,25 @@ The following is an annotated copy of a bundle:
         <Package name='ssh'/>
         <Service name='ssh'/>
       </Group>
+      <Client name='trust.example.com'>
+          <Path name='/etc/ssh/shosts.equiv'/>
+      </Client>
     </Bundle>
 
-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 **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
-how group entries can be used in bundles)
+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 **fc14** group, in
+which case, they get an extra package. The client
+**trust.example.com** gets one extra file that is not distributed to
+any other clients.  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 how group entries can be used in bundles)
 
 +----------------------------+-------------------------------+
-| Group                      | Entry                         |
+| Group/Hostname             | Entry                         |
 +============================+===============================+
 | all                        | /etc/ssh/ssh_host_dsa_key     |
 +----------------------------+-------------------------------+
@@ -101,6 +107,8 @@ how group entries can be used in bundles)
 +----------------------------+-------------------------------+
 | deb                        | Service ssh                   |
 +----------------------------+-------------------------------+
+| trust.example.com          | /etc/ssh/shosts.equiv         |
++----------------------------+-------------------------------+
 
 Genshi templates
 ================