Wird von der Elektra Initiative aus nicht angestrebt. Im Gegenteil, das Ziel von Elektra ist neutral zu allen Plattformen und Desktopumgebungen zu bleiben.
Elektra kann allerdings nach Journald loggen, und die INI Dateien von Systemd können natürlich in Elektra eingebettet werden. Z.b.:
sudo kdb mount /etc/systemd/system.conf system/systemd ini sudo kdb set system/systemd/Manager/LogLevel info
...und die INI Dateien von Systemd können natürlich in Elektra eingebettet werden.
Ich bezweifle dass das so funktionieren würde, außer von der INI-Datei verbleibt die letzte gültige Version auch dann im Dateisystem wenn Elektra nicht am laufen ist. Denn diese INI-Dateien müssen, zum Beispiel beim Hochfahren des Betriebssystem, schon da sein bevor Elektra läuft.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 02. Nov 2017 um 13:59.
Ich bezweifle dass das so funktionieren würde, außer von der INI-Datei verbleibt die letzte gültige Version auch dann im Dateisystem wenn Elektra nicht am laufen ist. Denn diese INI-Dateien müssen, zum Beispiel beim Hochfahren des Betriebssystem, schon da sein bevor Elektra läuft.
Elektra "läuft" immer, es ist eine Bibliothek und kein Daemon. Die genannten Befehle modifizieren die INI Datei persistent.
Auch eine Bibliothek muss erst einmal von irgendeiner anderen Komponente aufgerufen werden und welche das beim hochfahren des Betriebssystem sein soll hast du jetzt nicht spezifiziert, systemd selbst kennt jedenfalls kein Elektra.
Auch eine Bibliothek muss erst einmal von irgendeiner anderen Komponente aufgerufen werden und welche das beim hochfahren des Betriebssystem sein soll hast du jetzt nicht spezifiziert, systemd selbst kennt jedenfalls kein Elektra.
Achso, du fragst ob systemd tatsächlich schon Elektra verwendet, nicht ob es verwendet werden könnte?
Elektra implementiert verschiedene APIs, unter anderem open und getenv. Und ich habe tatsächlich schon mal ein komplettes Debian System umgestellt, so dass jeder getenv call nach Elektra ging.
In diesem System hat Elektra getenv-Abfragen wie SYSTEMD_LOG_TARGET, SYSTEMD_LOG_LEVEL, SYSTEMD_PAGER u.ä. tatsächlich beantwortet.
Du kannst es gerne auch selber überprüfen, du musst nur:
kdb elektrify-getenv | tail -1 | sudo tee -a /etc/ld.so.preload
Also wenn ich das richtig verstehe wird dadurch zum Beispiel jeder Versuch von systemd auf die Datei "/etc/systemd/system.conf" zuzugreifen erst einmal durch Elektra gejagt? Und was passiert wenn der PaketManager der Distribution wegen einem Update an der Datei etwas ändern will?
Also wenn ich das richtig verstehe wird dadurch zum Beispiel jeder Versuch von systemd auf die Datei "/etc/systemd/system.conf" zuzugreifen erst einmal durch Elektra gejagt?
Das kommt darauf an wie man Elektra verwendet:
Wenn man Dateien mountet, dann schreibt Elektra zwar in die Datei, das Programm welches die Datei verwendet hat aber ansonsten nichts mit Elektra zu tun.
Bei dem intercept-open ist es so wie von dir beschrieben. (Ist aber noch ein experimentelles Feature.)
Und was passiert wenn der PaketManager der Distribution wegen einem Update an der Datei etwas ändern will?
Elektra kann diese Situation sogar verbessern, da Elektra ein 3-way merge unterstützt:
Der 3-way merge arbeitet auf der Struktur, d.h. wenn man einfach nur Optionen anders anordnet, wird erkannt, dass der Inhalt der Datei eigentlich gleich ist.
Optionen die nur lokal oder nur von Maintainer verändert wurden, können auch konfliktfrei zusammengeführt werden.
Der 3-way merge funktioniert unabhängig davon wie Elektra verwendet wird.
Also das mit dem "Intercept File System" finde ich interessant und einleuchtend, allerdings dürfte die Doku dazu schon etwas besser sein. Die Nutzung über die Umgebungsvariable "LD_PRELOAD=/usr/local/lib/libelektraintercept.so" oder "/etc/ld.so.preload" wird dort nämlich nicht erwähnt.
"kdb elektrify-getenv" und das mit dem "3-way-merge" kapier ich irgendwie nicht so ganz.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Nov 2017 um 16:46.
Also das mit dem "Intercept File System" finde interessant und einleuchtend, allerdings dürfte die Doku dazu schon etwas besser sein. Die Nutzung über die Umgebungsvariable "LD_PRELOAD=/usr/local/lib/libelektraintercept.so" oder "/etc/ld.so.preload" wird dort nämlich nicht erwähnt.
"kdb elektrify-getenv" und das mit dem "3-way-merge" kapier ich irgendwie nicht so ganz.
Bei elektrify-getenv liegt dann ja die Konfiguration in /elektra/intercept/getenv, und dieser Bereich kann ja genauso gemerged werden wie jeder anderer Teil der key database (KDB).
Mir ist keine Anwendung bekannt, die Elektra voraussetzt. Eine Registry nur der Registry willen, ist aber wenig sinnvoll. Ich will ja nicht unken, aber solange die Nachfrage fehlt, sehe ich Elektra nur als nette Designstudie.
# PS Ein schönes Feature von Konfigurationsdateien # besteht m.E. darin, dass man Kommentare reinschreiben kann.
Mir ist keine Anwendung bekannt, die Elektra voraussetzt. Eine Registry nur der Registry willen, ist aber wenig sinnvoll. Ich will ja nicht unken, aber solange die Nachfrage fehlt, sehe ich Elektra nur als nette Designstudie.
Du hast natürlich Recht, dass eine nicht verwendete Bibliothek keinen Sinn macht. Nur muss man eine Bibliothek zuerst entwickeln bevor Sie verwendet werden kann. Unabhängig davon wird Elektra bereits verwendet, die meisten Anwendungen sind allerdings leider kommerziell. Unser Ziel ist aber, dass vor allem freie Software die Vorteile von Elektra bekommt. Darum arbeiten wir gerade daran, diverse freie Applikationen nach Elektra zu portieren. Neben dem bereits genannten Oyranos, elektrifizieren wir gerade LCDproc. In vielen anderen Fällen gibt es Interesse oder erste Schritte (z.b. machinekit.io, i3, ...).
Applikationen zu elektrifizieren ist allerdings nicht der einzige Weg wie Elektra verwendet werden kann (Elektra ist eben nicht nur eine Registry!):
Elektra kann dazu verwendet werden Konfigurationsdateien zu modifizieren ohne sich mit der Syntax beschäftigen zu müssen. Diese Funktionalität wird bei Configuration Management dringend benötigt. Seit diesem Release wird Puppet unterstützt. Alternativ bietet Elektra auch GUIs und bald Web-UIs an.
Elektra kann sich auch bei open und getenv einhängen (intercepten). Programme die getenv oder Konfigurationsdateien verwenden, verwenden dann automatisch Elektra. Es gibt auch experimentellen Support für GSettings.
# PS Ein schönes Feature von Konfigurationsdateien # besteht m.E. darin, dass man Kommentare reinschreiben kann.
Ja, das ist sehr wichtig und wird deshalb auch von Elektra unterstützt. Z.b. das ini und hosts Plugin ist gut darin Reihenfolge und Kommentare zu erhalten. Mittels "kdb getmeta keyname comment*", können Kommentare sogar programmatisch ausgelesen werden.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 02. Nov 2017 um 15:54.
Schön, dass sich hier ein Entwickler der Diskussion stellt. Auf jeden Fall war der Beitrag sehr erhellend (jedenfalls für mich, der vor einiger Zeit mal etwas von Elektra gelesen, das Ganze aber nicht weiter verfolgt hatte). Danke.
Wann wird das wohl in SystemD integriert?
Wird von der Elektra Initiative aus nicht angestrebt. Im Gegenteil, das Ziel von Elektra ist neutral zu allen Plattformen und Desktopumgebungen zu bleiben.
Elektra kann allerdings nach Journald loggen, und die INI Dateien von Systemd können natürlich in Elektra eingebettet werden. Z.b.:
Elektra "läuft" immer, es ist eine Bibliothek und kein Daemon. Die genannten Befehle modifizieren die INI Datei persistent.
Auch eine Bibliothek muss erst einmal von irgendeiner anderen Komponente aufgerufen werden und welche das beim hochfahren des Betriebssystem sein soll hast du jetzt nicht spezifiziert, systemd selbst kennt jedenfalls kein Elektra.
Achso, du fragst ob systemd tatsächlich schon Elektra verwendet, nicht ob es verwendet werden könnte?
Elektra implementiert verschiedene APIs, unter anderem open und getenv. Und ich habe tatsächlich schon mal ein komplettes Debian System umgestellt, so dass jeder getenv call nach Elektra ging.
In diesem System hat Elektra getenv-Abfragen wie SYSTEMD_LOG_TARGET, SYSTEMD_LOG_LEVEL, SYSTEMD_PAGER u.ä. tatsächlich beantwortet.
Du kannst es gerne auch selber überprüfen, du musst nur:
ausführen. Siehe auch getenv docu.Also wenn ich das richtig verstehe wird dadurch zum Beispiel jeder Versuch von systemd auf die Datei "/etc/systemd/system.conf" zuzugreifen erst einmal durch Elektra gejagt? Und was passiert wenn der PaketManager der Distribution wegen einem Update an der Datei etwas ändern will?
Das kommt darauf an wie man Elektra verwendet:
Elektra kann diese Situation sogar verbessern, da Elektra ein 3-way merge unterstützt:
Der 3-way merge funktioniert unabhängig davon wie Elektra verwendet wird.
Also das mit dem "Intercept File System" finde ich interessant und einleuchtend, allerdings dürfte die Doku dazu schon etwas besser sein. Die Nutzung über die Umgebungsvariable "LD_PRELOAD=/usr/local/lib/libelektraintercept.so" oder "/etc/ld.so.preload" wird dort nämlich nicht erwähnt.
"kdb elektrify-getenv" und das mit dem "3-way-merge" kapier ich irgendwie nicht so ganz.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Nov 2017 um 16:46.Danke, habe es hier gemeldet.
Bei elektrify-getenv liegt dann ja die Konfiguration in /elektra/intercept/getenv, und dieser Bereich kann ja genauso gemerged werden wie jeder anderer Teil der key database (KDB).
Mir ist keine Anwendung bekannt, die Elektra voraussetzt. Eine Registry nur der Registry willen, ist aber wenig sinnvoll. Ich will ja nicht unken, aber solange die Nachfrage fehlt, sehe ich Elektra nur als nette Designstudie.
# PS Ein schönes Feature von Konfigurationsdateien
# besteht m.E. darin, dass man Kommentare reinschreiben kann.
Von Oyranos wird es benutzt.
Du hast natürlich Recht, dass eine nicht verwendete Bibliothek keinen Sinn macht. Nur muss man eine Bibliothek zuerst entwickeln bevor Sie verwendet werden kann. Unabhängig davon wird Elektra bereits verwendet, die meisten Anwendungen sind allerdings leider kommerziell. Unser Ziel ist aber, dass vor allem freie Software die Vorteile von Elektra bekommt. Darum arbeiten wir gerade daran, diverse freie Applikationen nach Elektra zu portieren. Neben dem bereits genannten Oyranos, elektrifizieren wir gerade LCDproc. In vielen anderen Fällen gibt es Interesse oder erste Schritte (z.b. machinekit.io, i3, ...).
Applikationen zu elektrifizieren ist allerdings nicht der einzige Weg wie Elektra verwendet werden kann (Elektra ist eben nicht nur eine Registry!):
Ja, das ist sehr wichtig und wird deshalb auch von Elektra unterstützt. Z.b. das ini und hosts Plugin ist gut darin Reihenfolge und Kommentare zu erhalten. Mittels "kdb getmeta keyname comment*", können Kommentare sogar programmatisch ausgelesen werden.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 02. Nov 2017 um 15:54.Schön, dass sich hier ein Entwickler der Diskussion stellt.
Auf jeden Fall war der Beitrag sehr erhellend (jedenfalls für mich, der vor einiger Zeit mal etwas von Elektra gelesen, das Ganze aber nicht weiter verfolgt hatte).
Danke.