 |
Elektra 0.11.0
|
|
Elektra 0.11.0
|
In this tutorial we will go over mounting configuration files to enable non-elektrified applications to be configured through Elektra.
The best way of integrating Elektra into applications is to elektrify them.
To use Elektra with non-elektrified applications we can also let Elektra sync configuration files on the file system and Elektra's key-value storage. Applications can then read and write the configuration files and changes in the key database will be picked up by applications and vice-versa.
The heart of the approach is the so-called mounting of configuration files into the key database.
Let us start with a motivating example first:
We mount the lookup table with the following command:
/etc/hosts is the configuration file we want to mountsystem:/hosts is the path it should have in the key database, also known as mount pointhosts is the storage plugin that can read and write this configuration format.Consider using mount with the option
--with-recommends, which loads all plugins recommended by the hosts plugin. You can see the recommended plugins of hosts if you look at the output ofkdb plugin-info hosts. Hosts recommends the glob, network and error plugins. Using--with-recommends, more validation is done when modifying keys insystem:/hosts.
Now we use kdb file, to verify that all configuration below system:/hosts is stored in /etc/hosts:
After mounting a file, we can modify keys below system:/hosts. We need to be root, because we modify /etc/hosts.
These changes are reflected in /etc/hosts instantly:
Applications will now pick up these changes:
We are also safe against wrong changes:
We can undo these changes with:
Elektra manages its mount points in configuration below system:/elektra/mountpoints. The file that holds this configuration is, in the same way as /etc/hosts before, only writable by administrators:
Because of that only root can mount files.
The configuration file path you supplied to kdb mount above is actually not an absolute or relative path in your file system, but gets resolved to one by Elektra. The plugin that is responsible for this is the _Resolver_.
When you mount a configuration file the resolver first looks at the namespace of your mount point. Based on that namespace and if the supplied path was relative or absolute the resolver then resolves the supplied path to a path in the file system. The resolving happens dynamically for every kdb invocation.
You can display the mounted configuration files with kdb mount. Also here you only see the unresolved paths.
If you supplied an absolute path (e.g. /example.ini) it gets resolved to this:
| namespace | resolved path |
|---|---|
spec | /example.ini |
dir | ${PWD}/example.ini |
user | ${HOME}/example.ini |
system | /example.ini |
If you supplied a relative path (e.g. example.ini) it gets resolved to this:
| namespace | resolved path |
|---|---|
spec | /usr/share/elektra/specification/example.ini |
dir | ${PWD}/.dir/example.ini |
user | ${HOME}/.config/example.ini |
system | /etc/kdb/example.ini |
If this differs on your system, the resolver has a different configuration. Type kdb plugin-info resolver for more information about the resolvers.
There are different resolvers. For instance on non-POSIX systems paths must be resolved differently. In this case one might want to use the wresolver plugin. Another useful resolver is the blockresolver, which integrates only a block of a configuration file into Elektra.
But resolvers are not the only plugins Elektra uses:
Configuration files can have many different formats (ini, json, yaml, xml, csv, ... to name but a few).
One of the goals of Elektra is to provide users with a unified interface to all those formats. Elektra accomplishes this task with storage plugins.
In Elektra Plugins are the units that encapsulate functionality. There are not only plugins that handle storage of data, but also plugins that modify your values (iconv). Furthermore there are plugins that validate your values (validation, mathcheck, ...), log changes in the key set (logchange) or do things like executing commands on the shell (shell). You can get a complete list of all available plugins with
kdb plugin-list. Although an individual plugin does not provide much functionality, plugins are powerful because they are designed to be used together.
When you mount a file you can tell Elektra which plugins it should use for reading and writing to configuration files.
Elektra is able to store metadata of keys. The ni plugin and the dump plugin, among others, support this feature.
Metadata comes in handy if we use other plugins, than just the ones that store and retrieve data. I chose the ni plugin for this demonstration, because it supports metadata and is human-readable. So let us have a look at the type and mathcheck plugins.
By entering kdb plugin-info type in the commandline, we can find out how to use this plugin. It turns out that this plugin allows us to define a list of valid values for our keys via the metavalue check/enum.
You can have a look or even edit the configuration file with kdb editor user:/example ni to see how the value and metadata is stored:
The example shows an important problem: the configuration file is now changed in ways that might not be acceptable for applications. We have at least two ways to avoid that:
spec namespace, completely separate to the configuration files the application will seeIf you want to find out more about validation I recommend reading this tutorial next.
The plugins together with the configuration file form a backend. The backend determines how Elektra stores data below a mount point. You can examine every mount points backend by looking at the configuration below system:/elektra/mountpoints/<mount point>/.
One drawback of this approach is, that an application can bypass Elektra and change configuration files directly. If for example Elektra is configured to validate new configuration values before updating them, this is something you do not want to happen.
Another drawback is that mounting is static. In a previous example we mounted the /.git/config file into dir:/git. Now the dir namespace of every directory stores the configuration below dir:/git in this directories /.git/config file. And this mount point is the same for all users and all directories. So you can't have different configuration files for the same mount points in other directories. Because of the same reason you cannot have different configuration file names or syntax for the same mount point in the user namespace.
This is one of the reasons why Elektra promotes this naming convention for keys:
Key names of software-applications should always start with:
/<type>/<org>/<name>/<version>/<profile>
- type can be
sw(software),hw(hardware) orelektra(for internal configuration)
- org is an URL/organization name. E.g.
kde- name the name of the component that has this configuration
- version is the major version number. E.g. If your version is 6.3.8 than this would be
#6- profile is the name of the profile to be used. E.g.:
production,development,testing, ...
Furthermore, one cannot simply change the configuration file format, because it must be one the application understands. Thus one loses quite some flexibility (for instance if this file format doesn't support meta keys, as already mentioned).
These limitations are the reasons why elektrifing applications provides even better integration. Go on reading how to elektrify your application.
1.9.1