|
Elektra
0.9.3
|
If this FAQ does not contain your question, please open an issue. You can simply remove all template text and it is enough if the issue only contains your question. If you want you can label it as question, but we can also categorize it for you.
Please do not waste too much time to find something out yourself. Information where people get stuck is valuable to improve Elektra and its documentation. Even if you find out directly after you posted the question: the pointer can be helpful for other people having the same problem.
No, it is not. And even if it were, the story does not end with implementing a configuration file parser but, at least, you also need:
Every successful project has implemented many features Elektra has. But Elektra has the distinctive advantage that you can pick the features as you need them. Not used plugins do not cause any overhead or dependency. If you need new plugins or bindings, there is a community which can help you. Furthermore, Elektra has a defined API and you can swap implementations as needed.
So it pays off to use Elektra – in the short and in the long term.
Short answer: Try puppet-libelektra to see how useful it can be.
Longer answer:
Elektra abstracts configuration settings, something desperately needed within configuration management. Instead of rewriting complete configuration files, which might create security problems, Elektra operates precisely on the configuration setting you want to change: leaving others as chosen by the application or distribution. Furthermore, Elektra also allows us to specify configuration settings, which again brings benefits for configuration management tools.
Elektra is a radical step needed towards better configuration management: Let us fix how applications access configuration settings, so that we can properly access them, for example, from configuration management tools.
As an intermediate step, we can mount existing configuration files and operate on them.
Absolutely, you can think of libelektra as a small library in C that reads a configuration file and returns a data structure if you do not use any of its advanced features.
In fact, from the view of system-calls, a properly written configuration parser within your application would do exactly the same as Elektra does:
Writing configuration files is much more tricky, as Elektra avoids data loss in the case of concurrent writes, even if the other application does not use Elektra (this only works on modern file systems with high-resolution timestamps).
Elektra does not interfere with restarting. It is a passive library. It provides some techniques for reloading but they are optional. We recommend, however, that you keep the in-memory and persistent configuration always in sync via immediate writes on changes and immediate reloading after notifications.
In case of doubt please open an issue. If the question was already answered or is already in the documentation, we will simply point it out to you.
So do not worry too much, do not hesitate to ask any question. We welcome feedback, only then we can improve the documentation such as this FAQ!
Please check the issue tracker if it has already been reported. If it has not, please fill out the template. If you are in doubt, please report it.
Due to the modular architecture we can accept many contributions as plugins. Please only make sure that the README.md clearly states the purpose and quality of the plugin.
Please start by reading here.
New BSD license which allows us to have plugins link against GPL and GPL-incompatible libraries. If you compile Elektra, e.g., with GPL plugins, the result is GPL.
If you already use 0.8, you might want to continue using it until 1.0 is released. As announced here, the 0.9 series introduces incompatible changes as needed, in particular cleanup for the 1.0 release is done.
For details of versioning principles, see here.
1.8.13