Version: (using KDE KDE 3.4.0) Installed from: Gentoo Packages It would be great if KDE was configurated by and OpenLDAP server. example: - 2 servers with OpenLDAP configured and KDE Config files on it. - replication between them. - KDE Desktops after logging in (by OpenLDAP also?) check OpenLDAP servers for the config files and loads them on the Desktop. With OpenLDAP + kiosk would be excelent counterpart for Windows 2000+ with Active Directory for Roaming Profiles and locking down features in KDE without configuring all the workstations by and (or using nfs). I've search on google about this but found nothing. Posted on dot.kde.org and someone replied to talk to "Buchan Milne" and i've mailed him (waiting reply). I think it's one feature that pushes KDE more and more to business desktops.
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. ***