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).
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).