Elektra (Software)

Projekt zur Schaffung einer einheitlichen Schnittstelle zu Konfigurationinformationen von GNU/Linux-Software
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 26. Oktober 2018 um 18:06 Uhr durch Aka (Diskussion | Beiträge) (Schlüssel: Halbgeviertstrich). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Elektra ist eine Initiative mit dem Ziel, eine einheitliche Schnittstelle zu Konfigurationinformationen von Unix und Linux-Software zu schaffen. Die Konfigurationsinformationen sollen dabei in einem einheitlichen Format für Anwendungen verfügbar sein. Dazu dient eine einheitliche Elektra-API.[2]

Elektra
Basisdaten

Aktuelle Version 0.8.23
(Format invalid)
Betriebssystem Unix, Linux
Programmier­sprache C
Kategorie Konfiguration
Lizenz BSD-Lizenz
deutschsprachig nein
www.libelektra.org

Hintergrund

Programme, die für unixoide Systeme entwickelt werden, arbeiten zurzeit nicht mit einer zentralen Konfigurationsdatenbank, wie man es beispielsweise von Windows (die Registrierungsdatenbank) kennt. Die Flexibilität der bisher in Unix üblichen Konfigurationsdateien wird mehrheitlich als Vorteil betrachtet. Es ergeben sich dadurch jedoch auch einige Nachteile:[3]

  • Der Aufbau von Konfigurationsdateien ist nicht standardisiert und ist daher von Programm zu Programm unterschiedlich.
  • Die Position von Konfigurationsdateien innerhalb des Systems ist nur teilweise standardisiert und kann deshalb von System zu System variieren.
  • Aus den beiden obigen Problemen ergibt sich, dass es keine einheitliche Schnittstelle (API) gibt, mit der Programme auf die Konfigurationsinformationen zugreifen können. Jedes Programm kennt in erster Linie nur die eigene Konfiguration. Der Zugriff auf die Konfigurationen anderer Programme ist nicht oder nur eingeschränkt möglich.

Funktionalität von Elektra

Elektra ist in erster Linie eine Bibliothek, die den Anwendungen als Schnittstelle zu den Konfigurationsinformationen dient. Die Information wird – ähnlich der Registrierungsdatenbank von Windows – in einem Baum und mit Schlüsseln strukturiert. Es sind unterschiedliche Speicherformate und verteilte Speicherorte für die Konfigurationsinformationen vorgesehen. Wo und in welchem Format diese Informationen letztendlich gespeichert werden, lässt sich durch Auswahl eines entsprechenden Backends und sogenannte Mount points beeinflussen.[3] Damit die Elektra-Bibliothek möglichst vielseitig verwendbar ist, hat sie neben den C-Standard-Bibliothek keine zwingenden Abhängigkeiten. Auf die Verwendung eines Daemons wurde absichtlich verzichtet, um keinen „Single Point of Failure“ zu schaffen. Neben der Bibliothek entwickelt das Elektra-Projekt auch Tools (sowohl mit grafischer Oberfläche als auch als Kommandozeilentool), mit denen Benutzer die Konfigurationsinformationen einsehen und bearbeiten können.[2]

Backends

Durch das parallele Zugreifen auf die unterschiedlichsten Backendes wird eine ähnlich hohe Flexibilität erreicht, wie mit den bisher unter Unix üblichen Konfigurationsdateien. Dies stellt auch einen wesentlichen Unterschied zu anderen Konfigurationsdatenbank-Konzepten dar.[3] Backends die die Schlüssel in einer Dateisystemstruktur aus Ordnern und Dateien speichern. Eines das eine Berkeley DB nutzt und eines das INI-Dateien erstellt, wurden bisher entwickelt. Angedacht sind zusätzliche Backends, die im Format der xorg.conf-Datei, im Format der fstab-Datei, auf einem LDAP-Dienst, in XML-Dateien oder einer PostgreSQL-Datenbank die Konfigurationsinformationen speichern. Beliebige weitere Speicherformate, wie z. B. Datenbanken, PHP-Konfigurationsinformationen oder sogar Excel-Dateien, sind dank dem flexiblen Plug-in-System von Elektra vorstellbar. Es existiert ein Frontend-Plug-in, dass es erlaubt, Konfigurationen als XML-Datei aus Elektra zu exportieren und importieren. In der folgenden Tabelle sind Informationen über bereits existierende Backendes aufgelistet:[2]

Plug-in[4] Beschreibung
dump Elektra spezifisches Format
file Speichert Schlüssel als Ordner und Werte als Dateien im Dateisystem.
ini Speichert Schlüssel und Werte im Format der INI-Dateien.
berkeleydb Speichert Schlüssel und Werte in verschiedener Berkeley-Datenbanken.
augeas Auf der Augeas-Bibliothek basierende Konfigurationsdateien.
hosts Konfigurationen aus /etc/hosts
line Beliebige Text-Datei linienweise einlesen.
yajl JSON-Dateien
ni INI-Datei im Format der Nickel-Bibliothek
tcl Liest und schreibt Variablen aus oder zu einem Tcl-Script.
xerces beliebige XML-Struktur
xmltool XML-Struktur mit im Elektra-spezifischem Schema
simpleini Ermöglicht das Integrieren von INI-Dateien auf Systemen ohne GNU-C-Bibliothek.
mini INI-Dateien ohne Sektionen.
fstab Verarbeitet Dateien im Format der /etc/fstab
regexstore Liest und schreibt einzelne Werte anhand eines Reguläreren Ausdrucks.
csvstorage CSV-Tabellen
passwd Dateien im Format der /etc/passwd
dpkg Liest Metadaten aus einem dpkg-Paket.
mozprefs Einbinden von Mozilla-Konfigurationsdateien, wie sie für Firefox und Thunderbird genutzt werden.
c Schreibt eine C-Struktur.
camel Eine limitierte Variante von YAML-Dateien.
yamlcpp Integriert auf der C++-Bibliothek yaml-cpp basierende YMAL-Dateien.

Aufbau der Informationsstruktur

Schlüssel

Ähnlich wie die Windows-Registrierungsdatenbank verwendet Elektra eine Baumstruktur aus Schlüsseln, in der die Konfigurationsinformationen abgelegt wird. Schlüssel können, wie Ordner im Dateisystem, beliebig verschachtelt und verlinkt werden. Schlüssel, deren Namen mit einem Punkt (.) beginnen, sind inaktiv – sie können zwar über die Elektra-API ausgelesen werden, sollten aber von Anwendungen ignoriert werden. Dies entspricht dem Auskommentieren in Konfigurationsdateien und ermöglicht in Gegensatz zur Windows-Registrierungsdatenbank eine Dokumentation in der Konfigurationsdatenbank selbst zu erstellen.[3]

Die Schlüssel-Pfade der Elektra-Baum-Struktur weisen Ähnlichkeiten mit einem Unix-Dateisystem auf: Es gibt vergleichbar dem Stammverzeichnis einen systemweiten Stamm-Schlüssel. Die Schlüssel werden in einem Pfad mit einem Schrägstrich (/) voneinander getrennt. Werte werden mit einem Gleichheitszeichen (=) vom Schlüssel-Pfad abgegrenzt:

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

Einige Beispiele für festgelegte Schlüssel[2]:

Pfad in Elektra Inhalt bisherige Konfigurationsdatei oder Inhalt eines Verzeichnis in einem Linux/Unix-System nach FHS
system/ Host-spezifische Systemkonfiguration /etc/
user/ Konfigurationen des gerade aktuellen Benutzers ~/.*
user:root/ Konfigurationen des Systemadministrators /root/.*
user:$USER/ Konfigurationen eines bestimmten Benutzers /home/$USER/.*
system/filesystem/ Konfiguration der Mountpoints des Dateisystems /etc/fstab
system/elektra/ Konfiguration von Elektra selbst es gibt keine Entsprechung
system/elektra/mountpoints/ Konfiguration der Mountpoints von Elektra es gibt keine Entsprechung

Werte

Elektra unterstützt aus Einfachheitsgründen nur drei Datentypen, nämlich String (Text), Binary (Binärdaten, werden in Hexadezimalschreibweise ebenfalls als String gespeichert) und Links. Von der Verwendung von Binary wird jedoch abgeraten, da sie als „unmanageable blackboxes“ betrachtet werden.[3] Elektra arbeitet intern mit UTF-8, daher werden alle Strings vor der Speicherung in UTF-8 konvertiert.

Einzelnachweise

  1. Index of /ftp/elektra/releases. libektra.org, abgerufen am 29. Juni 2018.
  2. a b c d Markus Raab: The Elektra Initiative. (ODP) Linux in ein wirklich voll integriertes System verwandeln. libektra.org, 11. Mai 2006, abgerufen am 24. Januar 2014.
  3. a b c d e Markus Raab: A Modular Approach to Configuration Storage. (PDF) Diplomarbeit. Fakultät für Informatik der Technischen Universität Wien, 29. September 2010, abgerufen am 24. Januar 2014 (englisch).
  4. elektra-plugins(7) -- plugins overview. Abgerufen am 21. November 2017 (englisch).