Elektra (software)
| Elektra | |
|---|---|
| Basic data
|
|
| Current version | 0.8.26 (February 26, 2019) |
| operating system | Unix , Linux |
| programming language | C. |
| category | configuration |
| License | BSD license |
| German speaking | No |
| www.libelektra.org | |
Elektra is an initiative with the goal of a uniform interface to configuration information from Unix and Linux - Software to create. The configuration information should be available in a uniform format for applications. A uniform Elektra API is used for this .
background
Programs that are developed for Unixoid systems do not currently work with a central configuration database, as is known from Windows (the registry database ), for example . Most of the time, the flexibility of the configuration files used in Unix is seen as an advantage. However, this also has some disadvantages:
- The structure of configuration files is not standardized and therefore differs from program to program.
- The position of configuration files within the system is only partially standardized and can therefore vary from system to system.
- The result of the two problems above is that there is no uniform interface (API) with which programs can access the configuration information. Each program primarily only knows its own configuration. Access to the configurations of other programs is not possible or only possible to a limited extent.
Functionality from Elektra
Elektra is primarily a library that serves as an interface to the configuration information for the applications. Similar to the Windows registry database, the information is structured in a tree and with keys. Different storage formats and distributed storage locations are provided for the configuration information. Where and in which format this information is ultimately saved can be influenced by selecting an appropriate backend and so-called mount points . In order for the Elektra library to be as versatile as possible, it has no mandatory dependencies in addition to the C standard library . The use of a daemon was intentionally avoided in order not to create a “ single point of failure ”. In addition to the library, the Elektra project is also developing tools (both with a graphical user interface and as a command line tool) that users can use to view and edit the configuration information.
Backends
The parallel access to the most varied of backends achieves a similarly high level of flexibility as with the configuration files previously used under Unix. This also represents a significant difference to other configuration database concepts. Backends that store the keys in a file system structure made up of folders and files. One that uses a Berkeley DB and one that creates INI files have been developed so far. Additional backends are being considered, which will save the configuration information in the format of the xorg.conf file, in the format of the fstab file, on an LDAP service, in XML files or in a PostgreSQL database. Any other storage formats, such as. Thanks to the flexible plug-in system from Elektra, you can imagine, for example, databases, PHP configuration information or even Excel files . There is a front-end plug-in that allows configurations to be exported and imported from Elektra as XML files. The following table lists information about existing backend:
| Plug-in | description |
|---|---|
dump
|
Elektra specific format |
quickdump
|
Storage plugin is based on dump
|
file
|
Saves keys as folders and values as files in the file system. |
ini
|
Stores keys and values in the format of the INI files . |
dini
|
Proposed as a new default plugin |
berkeleydb
|
Stores keys and values in various Berkeley databases . |
augeas
|
On the Augeas - library -based configuration files. |
hosts
|
Configurations /etc/hosts
|
line
|
Read any text file line by line. |
yajl
|
JSON files |
ni
|
INI file in Nickel library format |
tcl
|
Reads and writes variables from or to a Tcl script. |
xerces
|
any XML structure |
xmltool
|
XML structure with the Elektra-specific scheme |
simpleini
|
Allows the integration of INI files on systems without a GNU C library . |
mini
|
INI files without sections . |
yamlsmith
|
Exports the key sets in the YAML format, only a limited subset supported by YAML |
typechecker
|
Checks the type of key specification |
regexdispatcher
|
Generates regex representation of the specification keywords |
fstab
|
Processes files in the /etc/fstab
|
regexstore
|
Reads and writes individual values using a regular expression . |
csvstorage
|
CSV tables |
passwd
|
Files in the /etc/passwd
|
dpkg
|
Reads metadata from a dpkg package. |
mozprefs
|
Integration of Mozilla configuration files , as used for Firefox and Thunderbird . |
c
|
Writes a C structure. |
camel
|
A limited variant of YAML files. |
yamlcpp
|
Integrates YAML files based on the C ++ library yaml-cpp.
|
yanrl
|
Uses parser generated by ANTLR to read YAML files |
yambi
|
Uses parser generated by Bison to read YAML files |
yawn
|
Uses parser generated by Earley to read YAML files |
yaypeg
|
Uses parser generated by PEG to read YAML files |
mmapstorage
|
Stores keys and values in memory mapped files |
Structure of the information structure
key
Similar to the Windows registry, Elektra uses a tree structure of keys in which the configuration information is stored. Like folders in the file system, keys can be nested and linked as required. However, any other metadata, e.g. B. Commenting out in configuration files is supported and, in contrast to the Windows registry database, enables documentation to be created in the configuration database itself.
The key paths of the Elektra tree structure show similarities with a Unix file system : There is a system-wide root key , comparable to the root directory . Keys are /separated from each other in a path with a slash ( ). Values are =separated from the key path with an equal sign ( ):
schlüssel_1/schlüssel_2=wert_1 schlüssel_1/schlüssel_2/schlüssel_3=wert_2 schlüssel_1/schlüssel_2/schlüssel_3=wert_3
Some examples of set keys:
| Path in Elektra | content | Previous configuration file or content of a directory in a Linux / Unix system according to FHS |
|---|---|---|
system/
|
Host- specific system configuration |
/etc/
|
user/
|
Configurations of the current user |
~/.*
|
dir/
|
Configurations in the current directory (as with .git) |
$PWD
|
spec/
|
Specification of configurations | there is no equivalent |
system/elektra/
|
Configuration by Elektra itself | there is no equivalent |
system/elektra/mountpoints/
|
Configuration of the mount points from Elektra | there is no equivalent |
values
For reasons of simplicity, Elektra only supports three data types, namely string (text), binary (binary data, are also stored as a string in hexadecimal notation) and links. The use of binary is not recommended, however, as they are viewed as "unmanageable blackboxes". Elektra works internally with UTF-8 , so all strings are converted to UTF-8 before being saved (using the iconv plugin).
Individual evidence
- ↑ Index of / ftp / elektra / releases. libektra.org, accessed February 27, 2019 .
- ↑ a b c d Markus Raab: The Elektra Initiative. ( ODP ) Turn Linux into a truly fully integrated system. libektra.org, May 11, 2006, accessed January 24, 2014 .
- ↑ a b c d e Markus Raab: A Modular Approach to Configuration Storage. (PDF) Diploma thesis. Faculty of Computer Science at the Vienna University of Technology, September 29, 2010, accessed on January 24, 2014 (English).
- ↑ elektra-plugins (7) - plugins overview. Accessed April 7, 2019 .