Libelektra: Question for collaboration: c# bindings to integrate elektra in Anthilla/Antd

[dorvan]

Hello,

I follow elektra project, as user, since it's named "Registry for Linux".
now we are working on Anthilla/Antd,
and looking to libelektra as inspiration, and why not, for integration.

At today there are c# bindings or updated documents on integrate liblelektra?

Thanks
Ivan

[markus2330]

Hello!

First of all: Thank you for writing us!

I follow elektra project, as user, since it's named "Registry for Linux".
now we are working on Anthilla/Antd,
and looking to libelektra as inspiration, and why not, for integration.

Great to hear that!

At today there are c# bindings

Unfortunately, currently there are no C# bindings for Elektra (maybe @nikonthethird started to write some but I never saw code).

Would you be interested to write C# bindings yourself?

@e1528532 or @domhof might be interested in helping you with the bindings and the integration.

or updated documents on integrate liblelektra?

We have written a tutorial, but obviously it does not cover C#.

Please do not hesitate to ask any question!

best regards,
Markus

[dorvan]

@markus2330 thanks for tutorial, not problem if does not cover c#,
if @e1528532 and/or @domhof are interested to help us for integration, we can define integration architecture and divide roles, or simply, we can define methods to "use" libelektra commands, as trigger for a "fast" integration.

for our application environment we refer to LiteDB a nosql db in c#.
we are working to close task on our active-active architecture, and we need a configuration backend to refer, or to develop.. at moment we have internal method to create/manage services configurations, but in future we need a more coherent backend as configuration management for services.

looking to "autoreplication" and self-updating we are searching for standalone (portable) or selfhosted pieces to include in our architecture...
also to be injected by ssh or webservice as needed.

I remember latest version of elektra i've used (2015) are really portable or standalone-able

[markus2330]

we can define integration architecture and divide roles, or simply, we can define methods to "use" libelektra commands, as trigger for a "fast" integration.

Some architectural description, or at least the interface you expect, would be of great help: then we would have a common understanding of what you want to achieve.

for our application environment we refer to LiteDB a nosql db in c#.

Is LiteDB relevant for the configuration settings?

we are working to close task on our active-active architecture, and we need a configuration backend to refer, or to develop.. at moment we have internal method to create/manage services configurations, but in future we need a more coherent backend as configuration management for services.

Elektra is an abstraction for configuration settings, which allows you to easily switch between configuration backends. So you can start to use it with some INI, XML or JSON files, and extend it later to better support your active-active architecture (if this is needed).

looking to "autoreplication" and self-updating we are searching for standalone (portable) or selfhosted pieces to include in our architecture...

Some architectural description explaining what exactly you mean by active-active, autoreplication, and self-updating in the context of your configuration needs would be helpful. You can also look into earlier questions from @mhaberler, you might share some requirements

also to be injected by ssh or webservice as needed.

ssh should be trivial (there is kdb import/export and a webservice is currently developed by @omnidan

I remember latest version of elektra i've used (2015) are really portable or standalone-able

Yes, we are still (and will be) completely portable (C99). Could you elaborate on standalone-able? Elektra is a library and does not rely on any external service/daemon/.. to work.

[dorvan]

@markus2330 perfect it's portable as i remember,

Architecture: our software Anthilla/Antd works as system manager, or orchestrator process, at omente we implements methods to manage single services or commands, like: bind, dhcpd, nftable, ssh/sshd, rsync, systemd, etc.. so any conf and any conf syntax need to be mapped.

In future we can rely on libelektra directly as configuration backend. so

(conf /etc)<->Elektra <->[box1 antd] <-----sync/cluster--------> [box antd]<->Elektra (conf/etc)

elektra (registry inspired) have inspired a lot of services like etcd and consul, ansible or salt, in the way to manage /etc, and applicative configuration. Antd it's another kind of system manager including web interface.

[markus2330]

Architecture: our software Anthilla/Antd works as system manager, or orchestrator process, at omente we implements methods to manage single services or commands, like: bind, dhcpd, nftable, ssh/sshd, rsync, systemd, etc.. so any conf and any conf syntax need to be mapped.

That sounds really interesting! Elektra is perfectly suitable to map many of these already, @BernhardDenner recently configured our own libelektra.org server completely with Elektra.

In future we can rely on libelektra directly as configuration backend. so

Okay, so the C# binding would not be the first step? How would you like to start?

elektra (registry inspired) have inspired a lot of services like etcd and consul, ansible or salt, in the way to manage /etc, and applicative configuration. Antd it's another kind of system manager including web interface.

Yes, etcd and consul have similar ideas but a completely different implementation (daemon vs. library). Ansible and salt (@BernhardDenner worked with puppet) is not something competing with Elektra but instead they would profit from Elektra being adapted more: Elektra takes away the burden related to configuration file editing. (libelektra itself is not a CM, you still need a tool that actively changes the configuration settings).

[dorvan]

Yes, etcd and consul have similar ideas but a completely different implementation (daemon vs. library). Ansible and salt (@BernhardDenner worked with puppet) is not something competing with Elektra but instead they would profit from Elektra being adapted more: Elektra takes away the burden related to configuration file editing. (libelektra itself is not a CM, you still need a tool that actively changes the configuration settings).

I know Elektra and I agree .
We make the CM and syncer. No problem.

Okay, so the C# binding would not be the first step? How would you like to start?

We think to implements methods and command triggers in order to use elektra by Antd directly.
For aconfiguration template: Can @BernhardDenner help us with a real-world template and conf asset or related tips and tricks for a server install?

Our OS it's gentoo Based, and i prefer to put Elektra into the application distribution, or separately. in a readonly image (squashfs.xz).

[markus2330]

Sorry for taking so long to respond. The work of @BernhardDenner is now complete and there will be a talk about it at FOSDEM. For the case study I talked about, see https://www.libelektra.org/ftp/elektra/publications/denner2018configuration.pdf
It shows in detail of how Elektra can be used within CM tool.

[markus2330]

@dorvan Is there any update?

[dorvan]

@markus2330 yes, we are working to a totally new version, and today I see your comments and can be really interesting for us especially for @BernhardDenner work.

We are working on a lot of project in data management/correlation and IoT using RAIC, "Redundant Array of Inexpensive Computer" or Destructure Cluster Array (both on System or Applicative side.)

[markus2330]

Having bindings for .net came again up as topic (in particular for F#). Are you still interested in the C# bindings? Would you also be able to put work into it?

[dorvan]

@markus2330 we still interested in c# because it's most used, and requires less packages to be supported in .net envs.

NEWS: we are working NOW, on antd re-asset, so we are looking for bindings or on the possibility to use elektra in selfhosted and standalone mode. including in application side, without installation.
We are also considering to use Kv db internally and map it with elektra.
we want to be able to have a only applicative standalone asseto to copy between systems and goes to manage configurations and actions (like ansible, puppet, salt, and anykind of other config management system and distribution or distribute managemente system) directly without depending on installed software. we are considering a recent linux system, with a minimal system + dotnet.

WELL KNOWN STATES and system configuration and core network components and services are the initial target.

[markus2330]

We are also considering to use Kv db internally and map it with elektra.

That would be amazing. Maybe you are then in the best position to write the binding as you know best about the requirements of your data structures?

manage configurations and actions (like ansible, puppet, salt, and anykind of other config management system and distribution or distribute managemente system)

This sounds very voluminous. Elektra currently has support for puppet and chef; Ansible is currently in the process of being vastly improved. Hopefully we are able to get this module upstream.

WELL KNOWN STATES and system configuration and core network components and services are the initial target.

Also this is wide. Elektra is currently focusing on application configuration, in particular we elektrify KDE, openHAB and LCDproc. But as we can configure everything (that maps to KV, which is everything), we are happy for any contributions that widens Elektra's applicability.

[kramlat]

still planning a dot net one? can you make it work with dotnet core and support c#, f#, and vb.net?

[kramlat]

I was hoping a version of aether desktop (a project of mine can use elektra as the base configuration system, here is what I have for a goal. Remember: Windows 10 will be discontinued 14th of october, 2025, so I want to build a linux distro for those that microsoft will leave behind, something similar, so I need a registry, which you provide, next I will need dbus, and powershell integration which means dotnet core, so I need to use either avalonia or gtk#, I will use both.

[markus2330]

Yes, we still would like to have it. Yesterday someone contacted me that he has interest in integration of LINQ-like languages. If he choses to work on LINQ, .NET bindings would be needed for that.

If you want it quickly and exactly as you need it, of course, doing it by yourself is the fastest way.

Btw. @mpranj is now also working on integrating Elektra in GNOME (besides to KDE).

[dorvan]

@markus2330 we are working on same directions, but on different bases, for example, we are interested to use Antd for a well knows config, role based, for entire system. so we need to use elektra like "dbus" to configure services, modules, kernel. and interchanging data to make whole system reactive.
The first problem (and the interest in elektra initiative) it's related to keep /etc simple and susbtitute it with a registry.
@kramlat the same for Us, we are working on the same things and we already using dotnet for everything in linux, moving almost all to user space. but for use the interest it's firstly server roles.

[dorvan]

@markus2330 firstly all things needed to work will be standalone or without external deps.

[markus2330]

for entire system

@tom-wa worked on elektrifying musl. It is quite hard work with many low-level problems. We stopped working on this for now.

so we need to use elektra like "dbus"

Elektra is not designed to replace a bus but to work together with buses. @waht implemented mechanisms for applications to send and receive notifications via dbus. @mpranj @FelixResch @darddan want to use Elektra-Dbus also for KDE/GNOME, so we will mature this mechanism soon.

firstly all things needed to work will be standalone or without external deps

It makes sense to use Elektra from the beginning (at least as optional backend), as Elektra is designed to encourage best practices (like that every configuration option gets an unique key name, that schemata are written for configuration in spec namespace and so on). Furthermore, it would be great to get feedback what already works for you and where you need improvements.