Changes

The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Mace is supposed to help with configuration of services on Server based school servers.

The mace is a tool to ma<strike>c</strike>ke final configuration using source templates. Mace is supposed to help with configuration of services on Server based school servers.

The core differences with tools like Puppet or Cfengine:

These are the core differences compared with tools like Puppet or Cfengine:

* mace doesn't provide new metaphors, people need to follow the same configuration syntax for particular services;

* mace doesn't provide new metaphors, people need to follow the same configuration syntax for particular services;

* mace is not intended to be an unified system like Puppet or Cfenginei, it supports only limited set of services (what Server based solution provides) but does it well, e.g., for iptables just write rules and the rest will be done by mace;

* mace is not intended to be a unified system like Puppet or Cfenginei, it supports only a limited set of services (what Server based solution provides), but does it well, e.g., for iptables, just write rules, and the rest will be done by mace;

* mace doesn't function like a daemon, it just converts configuration sources to the final configuration on the final server, e.g., as a post procedure after installing packages;

* mace doesn't function like a daemon, it just converts configuration sources to the final configuration on the final server, e.g., as a post procedure after installing packages;

* mace is designed to support intermediate customizing, i.e., the original configuration, provided by upstream project, might be supplemented (not patched) in downstream product before deploying to the final users.

* mace is designed to support intermediate customizing, i.e., the original configuration, provided by an upstream project, might be supplemented (not patched) in the downstream product before deploying to the final users.

== Configuration sources ==

== Configuration sources ==

  [<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 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 {{Code|service-confile}} is optional and makes sense only if the configured service has several of them, e.g., Bind. The {{Code|configuration-file}} is a configuration file in a particular service configuration's syntax. All {{Code|configuration-file}} files will be merged by mace to the singular {{Code|service-confile}} file and placed in the appropriate distribution-specific directory.

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:

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:

* hide previous configurations 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 the 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 shows how downstream tunes them:

  <dir>    +upstrem

  <dir>    +upstrem

  <empty>    +0300.proxy

  <empty>    +0300.proxy

See [http://git.sugarlabs.org/server/base/trees/master/etc sugar-server-base sources] for more complex example.

See [http://git.sugarlabs.org/server/base/trees/master/etc sugar-server-base sources] for a more complex example.

== Configuration applying ==

== Configuration application ==

Having configuration sources tree, mace will apply it to the real system by doing:

Mace will apply a configuration sources tree to the real system by doing the following:

# walk through the sources tree to collect all configuration source files for each supported service;

# walk through the sources tree to collect all configuration source files for each supported service;

# apply particular service configuration by saving files, the backup copies will be kept;

# apply the particular service configuration by saving files, the backup copies will be kept;

# ask mace provider of particular service to make sure that everything, related to this services, is good, e.g., check if Prosody SSL keys/certificates exist and not expired or if Squid's swap is created;

# ask mace provider of particular service to make sure that everything, related to this service, is good, e.g., check if Prosody SSL keys/certificates exist and are not expired, or check if Squid's swap is created;

# if new configuration is different to previous one or if 3) changed something in the system, restart this service;

# if a new configuration is different from a previous one, or if step 3 changed something in the system, restart this service;

# make sure if service will be started at boot time;

# make sure that service will be started at boot time;

# if all previous steps aborted due to fails, revert original configuration.

# if all the previous steps aborted due to failures, revert to the original configuration.

== Testing routines ==

== Testing routines ==

Before applying configuration on real system, it might be done to the temporary directory (do not forget about {{Code|--dry-services}} argument to not restart services):

Before applying a configuration on a real system, it might be applied to a temporary directory (do not forget about {{Code|--dry-services}} argument to not restart services):

  mace apply -o /tmp/test -S

  mace apply -o /tmp/test -S

Mace also supports several listing commands that just walk though the sources tree and print useful information about it:

Mace also supports several listing commands that just walk though the sources tree and print useful information about it:

* {{Code|mace ls}}, list sources status for particular directory;

* {{Code|mace ls}}, list sources status for a particular directory;

* {{Code|mace dirs}}, list sources status by services;

* {{Code|mace dirs}}, list sources status by services;

* {{Code|mace show}}, interpret services status given by {{Code|mace dirs}} command;

* {{Code|mace show}}, interpret services status given by {{Code|mace dirs}} command;

|-

|-

| {{Code|o}}

| {{Code|o}}

| some of configuration files are overridden by files with the same name but from different directory

| some of configuration files are overridden by files with the same name but from a different directory

|-

|-

| {{Code|O}}

| {{Code|O}}

| all configuration files are overridden by files with the same name but from different directory

| all configuration files are overridden by files with the same name but from a different directory

|-

|-

| {{Code|h}}

| {{Code|h}}

| some of configuration files are hidden by empty files with the same name but from different directory

| some of configuration files are hidden by empty files with the same name but from a different directory

|-

|-

| {{Code|H}}

| {{Code|H}}

| all configuration files are hidden by empty files with the same name but from different directory

| all configuration files are hidden by empty files with the same name but from a different directory

|-

|-

|}

|}