diff options
| -rw-r--r-- | doc/server/plugins/structures/altsrc.txt | 54 | ||||
| -rw-r--r-- | doc/server/plugins/structures/bundler/index.txt | 34 | ||||
| -rw-r--r-- | doc/unsorted/bundler_examples.txt | 102 | ||||
| -rw-r--r-- | doc/unsorted/dynamic_groups.txt | 15 | ||||
| -rw-r--r-- | doc/unsorted/mrepo.txt | 10 |
5 files changed, 108 insertions, 107 deletions
diff --git a/doc/server/plugins/structures/altsrc.txt b/doc/server/plugins/structures/altsrc.txt new file mode 100644 index 000000000..a84e9c72e --- /dev/null +++ b/doc/server/plugins/structures/altsrc.txt @@ -0,0 +1,54 @@ +.. -*- mode: rst -*- + +.. _server-plugins-structures-altsrc: + +=========================== +Fun and Profit using altsrc +=========================== + +Altsrc is a generic, bcfg2-server-side mechanism for performing +configuration entry name remapping for the purpose of data binding. + +Use Cases +========= + +* Equivalent configuration entries on different architectures with + different names +* Mapping entries with the same name to different bind results in a + configuration (two packages with the same name but different types) +* A single configuration entry across multiple specifications + (multi-plugin, or multi-repo) + +Examples +======== + +* Consider the case of /etc/hosts on linux and /etc/inet/hosts + on solaris. These files contain the same data in the same format, + and should typically be synchronized, however, exist in different + locations. Classically, one would need to create one entry for each in + Cfg or TCheetah and perform manual synchronization. Or, you could use + symlinks and pray. Altsrc is driven from the bundle side. For example: + + .. code-block:: xml + + <Bundle name='netinfo'> + <Group name='solaris'> + <Path name='/etc/inet/hosts' altsrc='/etc/hosts'/> + </Group> + <Group name='linux'> + <Path name='/etc/hosts'/> + </Group> + </Bundle> + + In this case, when a solaris host gets the 'netinfo' bundle, it will + get the first Path entry, which includes an altsrc parameter. This + will cause the server to bind the entry as if it were a Path + called ``/etc/hosts``. This configuration entry is still called + ``/etc/inet/hosts``, and is installed as such. + +* On encap systems, frequently multiple packages of the same name, but + of different types will exist. For example, there might be an openssl + encap package, and an openssl rpm package. This can be dealt with + using a bundle like: + + .. code-block:: xml diff --git a/doc/server/plugins/structures/bundler/index.txt b/doc/server/plugins/structures/bundler/index.txt index fc6e7244a..c5e360423 100644 --- a/doc/server/plugins/structures/bundler/index.txt +++ b/doc/server/plugins/structures/bundler/index.txt @@ -140,6 +140,14 @@ format can be used, as the target output format is XML. A Genshi template looks much like a Bundler file, except the Bundle tag has an additional `xmlns:py` attribute. See the examples. +Altsrc +====== + +.. toctree:: + :maxdepth: 1 + + ../altsrc + Examples -------- @@ -207,6 +215,32 @@ 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 + +In addition to the example repository, the following is a list of some +more complex example Bundles. + .. toctree:: :maxdepth: 1 diff --git a/doc/unsorted/bundler_examples.txt b/doc/unsorted/bundler_examples.txt deleted file mode 100644 index 442e9ce28..000000000 --- a/doc/unsorted/bundler_examples.txt +++ /dev/null @@ -1,102 +0,0 @@ -.. -*- mode: rst -*- - -.. _unsorted-bundler_examples: - -================ -Bundler 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 - -In addition to the example repository, the following is a list of some more complex example Bundles. To add your own example, create a wiki page called Plugins/Bundler/examples/<examplename> - -[[TitleIndex(Plugins/Bundler/examples/)]] - -=========================== -Fun and Profit using altsrc -=========================== - -Altsrc is a generic, bcfg2-server-side mechanism for performing configuration entry name remapping for the purpose of data binding. - -Use Cases -========= - -* Equivalent configuration entries on different architectures with different names -* Mapping entries with the same name to different bind results in a configuration (two packages with the same name but different types) -* A single configuration entry across multiple specifications (multi-plugin, or multi-repo) - -Examples -======== - -* Consider the case of /etc/hosts on linux and /etc/inet/hosts on solaris. These files contain the same data in the same format, and should typically be synchronized, however, exist in different locations. Classically, one would need to create one entry for each in Cfg or TCheetah and perform manual synchronization. Or, you could use symlinks and pray. Altsrc is driven from the bundle side. For example: - - .. code-block:: xml - - <Bundle name='netinfo'> - <Group name='solaris'> - <Path name='/etc/inet/hosts' altsrc='/etc/hosts'/> - </Group> - <Group name='linux'> - <Path name='/etc/hosts'/> - </Group> - </Bundle> - - In this case, when a solaris host gets the 'netinfo' bundle, it will get the first Path entry, which includes an altsrc parameter. This will cause the server to bind the entry as if it were a Path called '/etc/hosts'. This configuration entry is still called '/etc/inet/hosts', and is installed as such. - -* On encap systems, frequently multiple packages of the same name, but of different types will exist. For example, there might be an openssl encap package, and an openssl rpm package. This can be dealt with using a bundle like: - - .. code-block:: xml - - <Bundle name='openssl'> - <Package name='openssl' altsrc='openssl-encap'/> - <Package name='openssl' altsrc='openssl-rpm'/> - </Bundle> - - This bundle will bind data for the packages "openssl-encap" and "openssl-rpm", but will be delivered to the client with both packages named "openssl" with different types. - -* Finally, consider the case where there exist complicated, but completely independent specifications for the same configuration entry but different groups of clients. The following bundle will allow the use of two different TCheetah templates /etc/firewall-rules-external and /etc/firewall-rules-internal for different clients based on their group membership. - - .. code-block:: xml - - <Bundle name='firewall'> - ... - <Group name='conduit'> - <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/> - </Group> - <Group name='internal'> - <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-internal'/> - </Group> - </Bundle> - -* Consider the case where a variety of files can be constructed by a single template (TCheetah or TGenshi). It would be possible to copy this template into the proper location for each file, but that requires proper synchronization upon modification and knowing up front what the files will all be called. Instead, the following bundle allows the use of a single template for all proper config file instances. - - .. code-block:: xml - - <Bundle name='netconfig'> - <Path name='/etc/sysconfig/network-scripts/ifcfg-eth0' altsrc='/etc/ifcfg-template'/> - <Path name='/etc/sysconfig/network-scripts/ifcfg-eth1' altsrc='/etc/ifcfg-template'/> - <Path name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/> - </Bundle> - - 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/unsorted/dynamic_groups.txt b/doc/unsorted/dynamic_groups.txt index 87e858fec..e8d2de396 100644 --- a/doc/unsorted/dynamic_groups.txt +++ b/doc/unsorted/dynamic_groups.txt @@ -6,13 +6,22 @@ Dynamic Groups ============== -Bcfg2 supports the use of dynamic groups. These groups are not included in a client's profile group, but instead are derived from the results of probes executed on the client. These dynamic groups need not already exist in Metadata/groups.xml. If a dynamic group is defined in Metadata/groups.xml, clients that include this group will also get all included groups and bundles. +Bcfg2 supports the use of dynamic groups. These groups are not included +in a client's profile group, but instead are derived from the results +of probes executed on the client. These dynamic groups need not already +exist in ``Metadata/groups.xml``. If a dynamic group is defined in +``Metadata/groups.xml``, clients that include this group will also get +all included groups and bundles. Setting up dynamic groups ========================= -In order to define a dynamic group, setup a probe that outputs the text based on system properties:: +In order to define a dynamic group, setup a probe that outputs the text +based on system properties:: group:groupname -This output is processed by the bcfg2 server, and results in dynamic group membership in groupname for the client. See the [wiki:Plugins/Probes Probes] page for a more thorough description of probes. +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/mrepo.txt b/doc/unsorted/mrepo.txt index cae6e1dc0..61c3fd8c8 100644 --- a/doc/unsorted/mrepo.txt +++ b/doc/unsorted/mrepo.txt @@ -6,9 +6,15 @@ mrepo ===== -This page describes how to setup an [http://dag.wieers.com/home-made/mrepo/ mrepo] mirror. +This page describes how to setup an `mrepo`_ mirror. -mrepo builds a local APT/Yum RPM repository from local ISO files, downloaded updates, and extra packages from 3rd party repositories. It takes care of setting up the ISO files, downloading the RPMs, configuring HTTP access and providing PXE/TFTP resources for remote network installations. +.. _mrepo: http://dag.wieers.com/home-made/mrepo/ + +mrepo builds a local APT/Yum RPM repository from local ISO files, +downloaded updates, and extra packages from 3rd party repositories. It +takes care of setting up the ISO files, downloading the RPMs, +configuring HTTP access and providing PXE/TFTP resources for remote +network installations. Sample mrepo configuration ========================== |