.. -*- mode: rst -*-
.. _unsorted-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
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
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
...
* 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
altsrc can be used as a parameter for any entry type, and can be used
in any structure, including Bundler and Base.