diff options
Diffstat (limited to 'doc/unsorted/altsrc.txt')
| -rw-r--r-- | doc/unsorted/altsrc.txt | 67 |
1 files changed, 49 insertions, 18 deletions
diff --git a/doc/unsorted/altsrc.txt b/doc/unsorted/altsrc.txt index 248405ebc..251781d28 100644 --- a/doc/unsorted/altsrc.txt +++ b/doc/unsorted/altsrc.txt @@ -6,34 +6,52 @@ 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. +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) +* 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: +* 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'> - <ConfigFile name='/etc/inet/hosts' altsrc='/etc/hosts'/> + <Path name='/etc/inet/hosts' altsrc='/etc/hosts'/> </Group> <Group name='linux'> - <ConfigFile name='/etc/hosts'/> + <Path name='/etc/hosts'/> </Group> </Bundle> - In this case, when a solaris host gets the 'netinfo' bundle, it will get the first !ConfigFile entry, which includes an altsrc parameter. This will cause the server to bind the entry as if it were a !ConfigFile called '/etc/hosts'. This configuration entry is still called '/etc/inet/hosts', and is installed as such. + 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: +* 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 @@ -42,30 +60,43 @@ Examples <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. + 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. +* 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'> - <ConfigFile name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/> + <Path name='/etc/firewall-rules' altsrc='/etc/firewall-rules-external'/> </Group> <Group name='internal'> - <ConfigFile name='/etc/firewall-rules' altsrc='/etc/firewall-rules-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. +* 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'> - <ConfigFile name='/etc/sysconfig/network-scripts/ifcfg-eth0' altsrc='/etc/ifcfg-template'/> - <ConfigFile name='/etc/sysconfig/network-scripts/ifcfg-eth1' altsrc='/etc/ifcfg-template'/> - <ConfigFile name='/etc/sysconfig/network-scripts/ifcfg-eth2' altsrc='/etc/ifcfg-template'/> + <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, Base, and SGenshi. + altsrc can be used as a parameter for any entry type, and can be used + in any structure, including Bundler and Base. |