Changes

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