Re: [Registry] Some Thoughts...

[Markus R. <mai...@gm...>]

Am Freitag, 1. Oktober 2004 16:37 schrieb Jan Walzer:

> While browsing around the Elektra-Project caught my attention.
> I like the idea very much to have a consistent configuration scheme
> through the whole system and to use a simple storage.

ok, the idea is very good and both developer (don't have to redesign parsers 
again and again) and users (same configuration format) would profit. The 
problem up to now was, that no parser was good enough to fit all needs. I 
think elektra can do it.

> I've not yet found some documts, that describe the current technical
> state

It works well. There are also a lot of bindings, but i didn't test if they are 
bug-free.

> as how and where things in /etc are stored, but I suspect 
> them in the source package

man 5 elektra, i also didn't find it in the beginning :-) But this behavior is 
changeable by rewriting kdb. The apps using elektra will also work with 
another libkdb, they don't recognice the difference.

> On POSIX you simply use filesystem as backing store for every entry
> in the configuration files. Fine. So one can use the privileges
> supported by the OS, and FS-restrictions apply.

You have exactly the same behavior with elektra. It uses the FS-resctrictions 
of the OS. But you can change the behavior in the way you want to! You can 
even provide the exactly same state of configurationfiles as they are now 
with elektra. (dynamic libarys which load the correct libary for every 
configrationfile) But I think nobody likes that :-)

> But: If I understand correct, and as schon on some screenshots,
> Why do you limit yourself then to the static POSIX ACLs?
> Why only support (u,g,o)(r,w,[x]) in the frontend(kdb as I understand)?
> Why not leaving it completely to the FS to support extended ACLs?

ACLs are supported by elektra. But you are not able to set/get it within the 
api. If you want that feature, join us and contribute.

> This would make complex sceneries possible as allowing every user in
> a group modifying some other groups GECOS-field in passwd (for example).

It is possible to make GECOS-field editable and password not readable, even in 
the state today. Every field is a single file, so you can give it the mods 
you like.

> Another point, I'm maybe missing: A possibility to use templates or to
> define default values for some keys.

In work! It's a very difficult job. I will try to give comments for commenly 
used keys (documentation). In the comments there will also be default values 
and some other features.

> Currently every application has to do that for itself: read config in /etc
> and afterwards in ~/.app . 

I am writing an c++ binding, which do that automatically.

> Some are even more complex and have even more 
> configs that are read if they exist.

In that case you are invited to build a more complex binding :-)

> I'd propose to have default configs for an application in the /etc tree
> and to have the possibility to have a symlink (maybe call it "__default__")
> in every directory, that points to another directory, where the frontend
> tries to look if it can't find a requested key.

Symlinks are supported. Your described behavior can be done within a 
distribution (/etc/skel/.kdb keys and so on).

> This would allow applications
> to store a default config, supplied by the developer in
> /usr/share/doc/something
> or even better in /etc/elektra/sw/$APP/defaults as they currently do and
> the administrator can create some overrides into /etc.

Why /usr/share/doc/something? He can but it directly in the /etc. And he can 
write as much he wants to in the comment field.

> Later users can override these once again.
> For testing the admin can simply link to the default and override the
> settings.

You can do that anyway!

> kdb can then when a key is set by the user create it in the userdir,
> without overwriting the sysadmins setting.

The user is not able to overwrite sysadmin settings. What do you mean?

> This would also make software-upgrading simpler, as new configuration
> parameters get introduced in the default dir, but not yet set by the admin.

It is also planed to standardize the name of the keys. Then there would be no 
problem updating software.

> An application could expose all its available params in the default dir.

I doubt you know how some distributions solve the problem. I think it works 
well.

> Of course kdb would get a 'lil bit more complex,  because it probably has
> to do recursive lookups if a key is not found.

This can be done by a binding.

> The next point, that came to my mind when reading was, that there is no
> real migration path for current users. I think this is needed for users
> to accept elektra. There should be some way to manage configuration with
> elektra, without having to make every application elektra aware.

It is imposible :-) You have to elektrify all apps or the underlying 
configuration parsers (kconfig, gnome, fox-registry...) to make it elektra 
aware. A plan would be nice, but i think everybody is working as hard as he 
is able to.

> I've realized there are a lot converts that can read old-style-files and
> put them into elektra-keys. But I've not yet seen something, that reads
> elektra and creates legacy-output for standard-applications.

2 reasons for that:
- there are only converts for already elektrified apps
- with import/export you can use elektra to change the configuration-format. 
You "just" have to write elektra support for a configuration-format.

> I believe there should exist something like this, even better if this would
> be a named pipe as the old configfile. So one could have something
> daemon-like if it is needed. 

This is really useless, but you are welcome to write it :-)

> Pipes are located /etc on there old places and the keys 
> are stored somewhere completely different.

I think it would be easier and more useful to elektrify those apps.

> I'd furthermore propose to leave the idea of /etc for elektra.

Yes this could be done, when neary all apps are elektrified. It may come to a 
POSIX standard or at least an linux standard :-)

> If we have the chance to think about a new config scheme, why hang on old
> conventions? Make it clear, that it's different.

You are welcomed to create your favourite config scheme.

> Put the SYSTEM keys into /elektra. 

The Name would be /kdb. Elektra is just the public name for the project.

> Even further: I'd really like to think about, where the keys are stored
> in the tree. There is USER and there is SYSTEM. But does it really make
> sense to store the users GECOS field in the SYSTEM-subtree? maybe it does,
> but I'd suggest to think about this, and not copy the old behaviour where
> things are stored, only because they've been there for all the time.

Good thought. But some users don't have a home directory, there would be some 
difficults to store it in the user tree.

> Again: There is the chance to create a configuration-scheme, without
> compromises. One shouldn't revert to old habits but cut old tails now.

Yes, but to much changes will maybe be refused.

> And another thing that came to mind, when I read about the split between
> SYSTEM and USER. Nice. But IMHO also to short thought. Why this limit?
> Maybe there are also group-related values to store?

There is no limit for system and user. But only these names are mapped to real 
pathes up to now.

> And System? Why is a system static? I know I shouldn't compare with
> Windows, but I do. Windows knows "Hardware-profiles", where different
> configurations  apply depending on the current situation. So maybe I have 
> the tree  SYSTEM:HOME
> and SYSTEM:WORK and where SYSTEM supplies the current keys.

And how does elektra know what system to take? A configuration file for a 
configuration? Or a daemon which will lead to extreme security risks. You 
should also think about consequences and give us some ideas how to realize 
it. Anyway it is possible to copy the system Configuration, change it and 
decide with links what Configuration should be used. You can do that also 
with specific apps or even keys if you like to :-)

> And the value, which state the machine currently is in could then be stored
> somewhere in the real static keys as ELEKTRA/ .

Same as above, this would be a configuration for a confiugration library. What 
is if the configuration has syntax errors? The whole system will break. 
Imagine libc has a configuration!

> OK, I hope this won't be read as a flame, but instead of some
> "open-your-mind" thoughts. I think the project has the right idea behind, 
> but it will  probably miss its chance if it builds up on compromises and 
> legacy behaviour and doesn't have a working mirgration.

Migration is very difficult, I agree. But once migrated it would be not very 
difficult to change where keys are stored and so on. The problem would be 
then, that all distris use the same schemas...

> I'd like to contribute (at least some thoughts ;) to elektra, but I've
> not done a lot coding in C yet, as would be needed for the legacy wrappers
> for /etc.

Wrappers are more difficult to write than to elektrify (Which can be difficult 
enough in some cases).

Markus