Difference between revisions of "Platform Team/Server Kit/Mace"

From Sugar Labs
Jump to navigation Jump to search
(Created page with "The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Sources for {{Code|mace}} are stored in GNU/Linx distribution agnostic manner in form of:...")
 
Line 1: Line 1:
−
The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Sources for {{Code|mace}} are stored in GNU/Linx distribution agnostic manner in form of:
+
The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Sources for {{Code|mace}} are stored in GNU/Linux distribution agnostic manner in form of:
  
 
  [<arbitrary-path>]/<service-name>.d/[<service-confile>]/<configuration-file>.conf
 
  [<arbitrary-path>]/<service-name>.d/[<service-confile>]/<configuration-file>.conf
  
−
The {{Code|service-confile}} is optional and makes sense only if configured service has several of them, e.g., Bind. The {{Code|configuration-file}} are configuration files in particular service configuration syntax. All {{Code|configuration-file}} files will be merged to the singular {{Code|service-confile}} file and placed to the specific directory, depending on particular GNU/Linux distribution, by mace.
+
The {{Code|service-confile}} is optional and makes sense only if the configured service has several of them, e.g., Bind. The {{Code|configuration-file}} are configuration files in a particular service configuration syntax. All {{Code|configuration-file}} files will be merged to the singular {{Code|service-confile}} file and placed in the specific directory, depending on the particular GNU/Linux distribution, by mace.
  
−
The purpose to have {{Code|arbitrary-path}} is that there might be several directories with the same {{Code|service-name}}s to make configuration more flexible, i.e., it lets having several high-level configuration components in a project that configure the same service. Subsequent configuration might:
+
The purpose in having {{Code|arbitrary-path}} is that there might be several directories with the same {{Code|service-name}}s to make the configuration more flexible, i.e., it allows having several high-level configuration components in a project that configure the same service. Subsequent configuration might:
  
−
* supplement previous configuration by adding new {{Code|configuration-file}}s,
+
* supplement a previous configuration by adding new {{Code|configuration-file}}s,
−
* override previous configuration by having the same {{Code|configuration-file}} name with new content,
+
* override a previous configuration by having the same {{Code|configuration-file}} name with new content,
−
* hide previous configuration by having empty files with the same {{Code|arbitrary-path}} or {{Code|service-name}} name.
+
* hide previous configurations by having empty files with the same {{Code|arbitrary-path}} or {{Code|service-name}} name.
  
−
Such rules will be applied while walking within the root configuration directories tree when directory and file names are sorted alphabetically. The following example demonstrates virtual tree of upstream configuration with several high-level components and how downstream tunes them:
+
Such rules will be applied while walking within the root configuration directories tree when directory and file names are sorted alphabetically. The following example demonstrates the virtual tree of upstream configuration with several high-level components and how downstream tunes them:
  
 
  <dir>    +upstrem
 
  <dir>    +upstrem

Revision as of 13:33, 9 June 2011

The mace is a tool to macke final configuration using source templates. Sources for mace are stored in GNU/Linux distribution agnostic manner in form of: 

[<arbitrary-path>]/<service-name>.d/[<service-confile>]/<configuration-file>.conf

The service-confile is optional and makes sense only if the configured service has several of them, e.g., Bind. The configuration-file are configuration files in a particular service configuration syntax. All configuration-file files will be merged to the singular service-confile file and placed in the specific directory, depending on the particular GNU/Linux distribution, by mace.

The purpose in having arbitrary-path is that there might be several directories with the same service-names to make the configuration more flexible, i.e., it allows having several high-level configuration components in a project that configure the same service. Subsequent configuration might:

  • supplement a previous configuration by adding new configuration-files,
  • override a previous configuration by having the same configuration-file name with new content,
  • hide previous configurations by having empty files with the same arbitrary-path or service-name name.

Such rules will be applied while walking within the root configuration directories tree when directory and file names are sorted alphabetically. The following example demonstrates the virtual tree of upstream configuration with several high-level components and how downstream tunes them: 

<dir>    +upstrem
<dir>    |  +0100.base
<dir>    |  |  +iptables.d
<config> |  |     +0100.conf
<dir>    |  +0300.proxy
<dir>    |     +iptables.d
<config> |     |  +0300.squid.conf
<dir>    |     +squid.d
<dir>    +downstream
<dir>       +0100.base
<dir>       |  +iptables.d
<config>    |     +0110.addons.conf
<empty>     +0300.proxy
Retrieved from "https://wiki.sugarlabs.org/index.php?title=Platform_Team/Server_Kit/Mace&oldid=66302"