Difference between revisions of "Platform Team/Server Kit/Architecture"
(Created page with "== External services == Thats an important part of the Server, since it should configure core services that need to be provided by a server at schoo...") |
|||
| Line 5: | Line 5: | ||
=== Mace === | === Mace === | ||
| − | The mace is a ma< | + | 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: |
| + | [<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 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: | ||
| + | * supplement previous configuration by adding new {{Code|configuration-file}}s, | ||
| + | * override 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. | ||
| + | |||
| + | 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: | ||
| + | |||
| + | <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 | ||
== Internal services == | == Internal services == | ||
== Public API == | == Public API == | ||
Revision as of 06:31, 26 May 2011
External services
Thats an important part of the Server, since it should configure core services that need to be provided by a server at school. The configuration happens in GNU/Linux agnostic manner, basing on mace utility.
Mace
The mace is a tool to macke final configuration using source templates. Sources for mace are stored in GNU/Linx 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 configured service has several of them, e.g., Bind. The configuration-file are configuration files in particular service configuration syntax. All configuration-file files will be merged to the singular service-confile file and placed to the specific directory, depending on particular GNU/Linux distribution, by mace.
The purpose to have arbitrary-path is that there might be several directories with the same service-names 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:
- supplement previous configuration by adding new
configuration-files, - override previous configuration by having the same
configuration-filename with new content, - hide previous configuration by having empty files with the same
arbitrary-pathorservice-namename.
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:
<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