Provided by: elektra-doc_0.8.14-5_all 
NAME
md_doc_help_elektra-architecture - elektra-architecture
• infos = Information about the conditionals plugin is in keys below
• infos/author = Thomas Waser thomas.waser@libelektra.org
• infos/licence = BSD
• infos/needs =
• infos/provides =
• infos/placements = presetstorage
• infos/description =
This plugin uses if-then-else like conditions stored in the metakey check/condition to
validate data.
Syntax
(IF-condition) ? (THEN-condition) : (ELSE-condition) where the ELSE-condition is optional
Condition: Key Operation `('String' | '1234.56' | Key | '')`
Operations: !=, ==, <, <=, =>, >, :=, where:
• := is used to set a key value
• others are for comparison as in C
Example
`(this/key != 'value') ? (then/key == some/other/key) : (or/key <= '125')`
Meaning: IF this/key NOT EQUAL TO 'value' THEN then/key MUST EQUAL some/other/key ELSE
or/key MUST BE LESS THAN 125
Another full example:
kdb mount conditionals.dump /tmount/conditionals conditionals dump
kdb set user/tmount/conditionals/fkey 3.0
kdb set user/tmount/conditionals/hkey hello
kdb setmeta user/tmount/conditionals/key check/condition "(hkey == 'hello') ? (fkey == '3.0')" # success
kdb setmeta user/tmount/conditionals/key check/condition "(hkey == 'hello') ? (fkey == '5.0')" # fail
int configuration** as shown
in the example below. fstab is a unique name within the mount point configuration
provided by the administrator.
Example for a mount point configuration:
system/elektra/mountpoints system/elektra/mountpoints/fstab
system/elektra/mountpoints/fstab/config
system/elektra/mountpoints/fstab/config/path=fstab
system/elektra/mountpoints/fstab/config/struct=list FStab
system/elektra/mountpoints/fstab/config/struct/FStab
system/elektra/mountpoints/fstab/config/struct/FStab/device
system/elektra/mountpoints/fstab/config/struct/FStab/dumpfreq
system/elektra/mountpoints/fstab/config/struct/FStab/mpoint
system/elektra/mountpoints/fstab/config/struct/FStab/options
system/elektra/mountpoints/fstab/config/struct/FStab/passno
system/elektra/mountpoints/fstab/config/struct/FStab/type
system/elektra/mountpoints/fstab/errorplugins
system/elektra/mountpoints/fstab/errorplugins/#5#resolver#resolver#
system/elektra/mountpoints/fstab/getplugins
system/elektra/mountpoints/fstab/getplugins/#0#resolver
system/elektra/mountpoints/fstab/getplugins/#5#fstab#fstab#
system/elektra/mountpoints/fstab/mountpoint /fstab
system/elektra/mountpoints/fstab/setplugins
system/elektra/mountpoints/fstab/setplugins/#0#resolver
system/elektra/mountpoints/fstab/setplugins/#1#struct#struct#
system/elektra/mountpoints/fstab/setplugins/#2#type#type#
system/elektra/mountpoints/fstab/setplugins/#3#path#path#
system/elektra/mountpoints/fstab/setplugins/#3#path#path#/config
system/elektra/mountpoints/fstab/setplugins/#3#path#path#/config/path/allow=proc tmpfs none
system/elektra/mountpoints/fstab/setplugins/#5#fstab
system/elektra/mountpoints/fstab/setplugins/#7#resolver \nd{lstlisting}
Let us look at the subkeys below the key system/elektra/mountpoints/fstab:
• config: Everything below {config} is the system's configuration of the backend. Every
plugin within the backend will find this configuration directly below {system/} in its
{plugin configuration}. For example,
system/elektra/mountpoints/fstab/config/struct/FStab/mpoint
will be translated to
system/struct/FStab/mpoint
and inserted into the plugin configuration for all plugins in the fstab backend.
It is the place where configuration can be provided for every plugin of a backend. The
contract checker deduces this configuration to satisfy the contract for a plugin. Fstab,
for example, claims in a contract that it needs ''struct''. But the struct plugin needs a
configuration to work properly. Fstab will provide this configuration. The {contract
checker} writes out the configuration looking like the one in this example.
• config/path: is a common setting needed by the resolver plugin. It is the relative path
to a filename that is used by this backend. On UNIX systems, the resolver would
determine the name /etc/fstab for system configuration.
• mountpoint: is a key that represents the mount point. Its value is the location where
the backend is mounted. If a mount point has an entry for both the user and the system
hierarchy, it is called {cascading mount point}. A cascading mount point differs from
two separate mount points because internally only one backend is created. In the
example, the mount point /fstab means that the backend handles both user/fstab and
system/fstab. If the mount point is /, the backend will be mounted to all namespaces
except spec, including both user and system.
• errorplugins: presents a list of all plugins to be executed in the error case of
kdbSet() which will be explained in {error situation}.
• getplugins: is a list of all plugins used when reading the configuration from the key
database. They are executed in kdbGet().
• setplugins: contains a list of all plugins used when storing configuration. They are
executed in kdbSet().
Each of the plugins inside the three lists may have the subkey config. The configuration
below this subkey provides plugin specific configuration. This configuration appears in
the user's configuration of the plugin. Configuration is renamed properly. For example,
the key
system/elektra/mountpoints/fstab/setplugins/#3#path#path#/config/path/allow
is transformed to
user/path/allow
and appears in the plugin configuration of the path plugin inside the fstab backend.
Referencing
The same plugin often must occur in more than one place within a backend. The most common
use case is a plugin that has to be executed for both kdbGet() and kdbSet(). It must be
the same plugin if it preserves state between the executions.
Other plugins additionally have to handle error or success situations. One example of
exceptional intensive use is the resolver plugin. It is executed twice in kdbSet(). In
kdbGet() it is also used as shown in Listing~lst:mount point configuration}.
[language=]{#n<name>} introduces a new plugin from the module name which cannot be
referenced later. The cypher n appoints the actual placement of the plugin.
[language=]{#n#<name>#<label>#} also introduces a new plugin from the module name and
gives it the name label. The last [language=]{#} shows that a new name is being
introduced. [language=]{#n#<ref>} references back to a label which was introduced before.
This configuration does not create a new plugin. kdb mount already implements the
generation of these names as described above.
Changing Mount Point Configuration
When the user changes the mount point configuration, without countermeasures, applications
already started will continue to run with the old configuration. This could lead to a
problem if backends in use are changed or removed. It is necessary to restart all such
programs. Notification is the best way to deal with the situation. Changes of the mount
point configuration, however, do not occur often. For some systems, the manual restart may
also be appropriate.
In this situation, applications can receive warning or error information if the
configuration files are moved or removed. The most adverse situation occurs if the
sequence of locking multiple files produces a {dead lock}. Under normal circumstances, the
sequence of locking the files is deterministic, so either all locks can be requested or
another program will be served first. But several programs with different mount point
configurations running at the same time can cause a disaster. The problem gets even worse,
because kdb mount is unable to detect such situations. Every specific mount point
configuration for itself is trouble-free.
But still a dead lock can arise when multiple programs run with different mount point
configurations. Suppose we have a program A which uses the backends B1 and B2 that
requests locks for the files F1 and F2. Then the mount point configuration is changed. The
user removes B1 and introduces B3. B3 is in a different path mounted after B2, but also
accesses the same file F1. The program B starts after the mount point configuration is
changed. So it uses the backends B2 and B3. If the scheduler decides that first A and then
B both successfully lock the files F1 and F2, a dead lock situation happens because in the
afterwards the applications A and B try to lock F2 and F1.
A manual solution for this problem is to enable kdb to output a list of processes that
still use old mount point configuration. The administrator can restart these processes.
The preferred solution is to use notification for mount point configuration changes or
simply to use a lock-free resolver.
Continue reading with the data structures.
Version 0.8.14 Tue Dec 15 201md_doc_help_elektra-architecture(3elektra)