Projects / Elektra Initiative

Elektra Initiative

Elektra is a universal hierarchical configuration store, similar to GConf and the Windows Registry. It allows programs to read and save their configurations with a consistent API, and allows them to be aware of other applications' configurations, leveraging easy application integration. While architecturally similar to other OS registries, Elektra does not have most of the problems found in those implementations. Elektra includes a library, an API, and commandline and GUI tools for administration tasks.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  17 Oct 2008 18:08

    No changes have been submitted for this release.

    •  30 Mar 2006 22:11

      Release Notes: Some bugs were fixed, and the code was adapted to the Elektra API changes found in 0.6.

      •  30 Mar 2006 22:10

        Release Notes: The API and ABI are now more flexible and thread safe, more key searching options were added, and the Berkeley DB backend is now fully functional.

        •  08 Mar 2006 20:10

          Release Notes: Some bug fixes and UI improvements.

          •  08 Mar 2006 20:09

            Release Notes: The Berkeley DB backend is ready for production. Some new practical methods have been added, as well as better support for nicer and more clean XML exporting.

            Recent comments

            13 Oct 2004 08:19 LordFalcon

            Idea...
            Imho the approach of using win like registry is a bad idea. But what could be done is(I think it was already tried or something) is to still keep the normal configuration files but get them parsed into and shown if you care like registry... butthen it would still store them back to the old format... basicaly you combine the best possible approach with this one...

            30 Aug 2004 13:16 drynish

            Re: I really don't like the name
            Maybe something like modernetc or something with these letters. I read all the comments and starts thinking that this would really be a great idea but will surely takes a great deal of effort to come at life. We will see... I don't think there's a future thought

            >

            > % I really think we should do something

            > better .....

            >

            >

            > What you sugest?

            > Other similar projects are less popular

            > because they have

            > different names.

            > Also, I'm trying to address the MS

            > registry's problems like

            > centralization, etc.

            >

            27 Jul 2004 23:53 fnevgeny

            Re: Approach


            > A filesystem is one possible backend. Is

            > provides automatic hierarchy, security

            > etc. Other implementations may come.

            I didn't see any stubs in the code for a kind of "backend plugin" mechanism.

            > LR is not for enterprise cross-server

            > administration. For this, use LDAP, NIS,

            > etc.

            I meant enterprise level of managing workstations also.

            > LR was created to substitute

            > human-readable text configuration files

            > only.

            I know, and it's wrong IMHO. You're trying to implement functionality of MS registry, but its ideology is outdated; it's already at least one-generation old even in the MS world. I fully agree that it's a way better than the current zoo of Unix configuration schemes/formats, but are you serious about persuading a major part of Linux/Unix developers/vendors something so dated is worth a _lot_ of efforts to convert to? I doubt so.

            > Because precisely RDBMS is dumbness.

            ??

            > RDBMS is not available for early boot

            > stage programs, like /sbin/init,

            Depends on RDBMS. With e.g. SQLite you get it immediately. Also, according to your logic, it's impossible to use LDAP on localhost for authentication. But PAM nicely prooves otherwise. Again, because it use a smart plugin/augumenting approach. For initial system setup, plain text files works, and when the LDAP server is ready, it extends the initial small auth DB. But all apps linked to libpam know knowthing about it.

            > and

            > RDBMS are a too complex substitute for

            > simple text files. It is a sandbox,

            > problematic to administer in critical

            > situations.

            Come on, a corrupted filesystem (especially with many thousands of inodes) isn't easier to deal with than a corrupted RDBMS storage. Tell it to banks etc which trust these sandboxes to store transactions worth of billions of bucks. It's all about backups and reliability of design.

            > Please read the specs before

            > argumenting.

            I did.

            27 Jul 2004 15:10 aviram

            Re: Approach


            > Nope. Using FS in this manner is a dead

            > end with no feasible way of solving

            > scalability problems. It's even more

            > doomed than gconf. Try to estimate the

            > number of inodes per user assuming all

            > apps switched to LR. You'll easily count

            > thousands; for true multi-user systems,

            > that'll go to hundreds of thousands.

            %

            A filesystem is one possible backend. Is provides automatic hierarchy, security etc. Other implementations may come. The main point is the API and the keys namespace. Possible options are unique text file per folder, etc.

            > And

            > what about enterprise-level

            > configuration management?!

            %

            LR is not for enterprise cross-server administration. For this, use LDAP, NIS, etc. LR was created to substitute human-readable text configuration files only.

            > Not to mention inherited dumbness of

            > such a configuration storage. Why not

            > use a smart backend, e.g. an RDBMS? Just

            > imagine what kind of unparalleled power

            > and flexibility one gets with

            > views/triggeres/... And you get

            > rollback/replication/... for free.

            %

            Because precisely RDBMS is dumbness. RDBMS is not available for early boot stage programs, like /sbin/init, and RDBMS are a too complex substitute for simple text files. It is a sandbox, problematic to administer in critical situations.

            Please read the specs before argumenting. All the points you mentioned are explained there.

            27 Jul 2004 14:15 fnevgeny

            Re: Approach


            > I like idea of using filesystem as

            > backend, any

            > performance issues (if there would be

            > any) are fs

            > problems.

            Nope. Using FS in this manner is a dead end with no feasible way of solving scalability problems. It's even more doomed than gconf. Try to estimate the number of inodes per user assuming all apps switched to LR. You'll easily count thousands; for true multi-user systems, that'll go to hundreds of thousands. And what about enterprise-level configuration management?!

            Not to mention inherited dumbness of such a configuration storage. Why not use a smart backend, e.g. an RDBMS? Just imagine what kind of unparalleled power and flexibility one gets with views/triggeres/... And you get rollback/replication/... for free.

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.