Bug 101716

Just like the other requests to have config files stored in Linux Registry, Elektra, gconf, etc...

well, i don't think. using ldap for enterprise usage is great and has a lot of features that really help sysadmins out.

the real cool feature that kde would have if porting ALL config files to ldap is everyone could logon to diferent workstations and use the configs that the user configured. not to mention kiosk :)

wierd ideia:

KConfigEditor modified to write in multiple backends.
KDE modified to have multiple backends for config loading.

(i'm suposing that access to configs are in the KDELibs)

I have some interest in this, and have asked someone to take a look at the feasibility ...

There are a few issues that need to be resolved:

1)When should configuration in LDAP be searched for?

2)How should authentication work?

3)How should the server to query be located?

4)How should searches look (where in the DIT should they be looked for etc)

5)How much of the above can be determined automagically (ie without configuring the configuration backend)

6)How should the schema look?

Taking (1), (2) and (3) together, it may be worthwhile to require an LDAPv3 (LDAP+kerberos) setup for totally automagic setup. Then, if the user has a kerberos ticket, LDAP SRV records could be queried for the server to use, and if they exist, a search should be done on the server (with some basedn) for entries of the objectclass used to store configuration entries.

It could be possible (for organisations that don't have a full setup) to have a configuration file for some of this.

For (4), you would want to be able to support both user-specific configuration (ie ~/.kde/share/config) and per-group configuration (similar in some ways to kiosk-style), and global configuration.

When using LDAPv3+Kerberos, an extended operation on an LDAP server that supports determining the DN of the user (such as OpenLDAP, but not AD, maybe not others) can be used (see ldapwhoami for example). From there group memberships could be determined. So, if the uid were something like uid=fred,ou=People,dc=kde,dc=org, with a default group of cn=engineering,ou=Group,dc=kde,dc=org we might do 3 searches, one each under cn=Config,uid=fred,ou=People,dc=kde,dc=org, cn=Config,cn=engineering,ou=Group,dc=kde,dc=org, and cn=Config,dc=kde,dc=org.

So, regarding (5) ... it may (under certain circumstances) be possible to do most of (1) to (4) automagically.

Now, the remaining issue is the schema design. I think it may be feasible to do something like this in GConf as well ... in which case catering for reusing of the schema would not be a bad idea (since that would simplify server setup, indexing etc).

For KDE applications, it may be best to have one LDAP corresponding to each section of an rc file. So, taking something like kcalcrc, which might look something like this:

[Colors]
BackColor=189,255,180
ForeColor=0,0,0
FunctionButtonsColor=230,231,230
HexButtonsColor=230,231,230
MemoryButtonsColor=230,231,230
NumberButtonsColor=230,231,230
OperationButtonsColor=230,231,230

[Font]
Font=helvetica,14,-1,5,75,0,0,0,0,0

We might then look at having LDIF like this:

cn=kcalcrc,ou=Config,uid=fred,dc=kde,dc=org
ObjectClass=appConfig
cn=kcalcrc

cn=Colors,cn=kcalcrc,ou=Config,uid=fred,dc=kde,dc=org
Objectclass: appConfigSection
cn: Colors
app: kcalcrc
entry: BackColor=189,255,180
entry: ForeColor=0,0,0
entry: FunctionButtonsColor=230,231,230
entry: HexButtonsColor=230,231,230
entry: MemoryButtonsColor=230,231,230
entry: NumberButtonsColor=230,231,230
entry: OperationButtonsColor=230,231,230

cn=Font,cn=kcalcrc,ou=Config,uid=fred,dc=kde,dc=org
Objectclass: appConfigSection
cn: Font
app: kcalcrc
entry: Font=helvetica,14,-1,5,75,0,0,0,0,0

(the "=" in the attributes would have to be escaped ... but we'll ignore that for now)

So, search filters would be something like (&(objectClass=appConfigSection)(app=kcalcrc))

Searching should never need to be done on the entries form the sections of the config file, so it shouldbe sufficient to have just one attribute name used for them.

Anyway, that's a start to this, and what I have been thinking about. (Jose, I got your mail ... a few weeks after you sent it since it was mailed to my spammed-to-death account which I've redirected to a webmail account ... and since then I've been quite busy on other projects, but we may have some resources available to look at this now. So sorry for the delay ...).

Created attachment 11703 [details]
appconfig schema draft

OK, I've drafted a schema, which I will attach. It differs slightly from what I
described in the previous comment.

We have got the schema in use on one of our (non-production) internal LDAP
servers, with the modified ldif shown above (which I will also attach).

Created attachment 11704 [details]
kcalcrc example converted to LDIF using appconfig.schema

Here is a patch for libkdecore.so, it was written for KDE 3.4 but should work fine for KDE 3.3 as well, it implements an ldap backend, and creates both (ini and ldap) backends for every KConfig object. 

In this patch

1. the LDAP parser is called first so everything marked there as immutable will stay. 

2. Only parsing global values is implemented here. 

Created attachment 12165 [details]
LDAP BackEnd Patch

*** This bug has been confirmed by popular vote. ***

Hi,

kdelibs (version 4 and earlier) is no longer maintained since a few years.

KDE Frameworks 5 or 6 might already have implemented this wish.

If not, please re-open against the matching framework if feasible or against the application that shows the issue.

We then can still dispatch it to the right Bugzilla product or component.

Greetings
Christoph Cullmann