Re: nice /. comment

[Kristian Rietveld <kris math leidenuniv nl>]

On Sat, 2003-02-22 at 17:47, Havoc Pennington wrote:
> On Sat, Feb 22, 2003 at 08:20:01AM -0800, George Farris wrote:
> > On Fri, 2003-02-21 at 21:06, Havoc Pennington wrote:
> > 
> > > I would appreciate suggestions on what you'd like to see in order to
> > > prioritize the key points.
> > > 
> > > Havoc
> > 
> > Now that I've opened my big fat yap I guess I'd better step up to the
> > plate so to speak.  I'm interested in LDAP support what can I do to
> > help?
> 
> Something that'd help me a lot there is to look at Kristian's proposed
> LDAP support, and see if the way he's storing the data in LDAP would
> be manageable or if you can think of better ways to do it. Kristian
> maybe you could post a summary of how the LDAP backend works?

Sure, here follows a short overview. Basically this is what Jeff and I
came up with.

First, we have the file ${prefix}/etc/gconf/2/ldap. This file contains
"definitions" of possible LDAP connections, each uniquely identified by
a nickname. A simple example:

[pants]
host = localhost
bind_dn = dc=rietveld,dc=nl
bind_pwd = blaat
storage_dn = cn=GConf,uid=gnome2,ou=people,dc=rietveld,dc=nl

host speaks for itself I guess. bind_dn is the DN to bind too, with the
password specified by bind_pwd (yes, this is a bit insecure maybe). Then
storage_dn points to the folder with GConf keys. It might be handy to
replace uid=gnome2 with something like uid=%u.

A gconf.path file would contain:

ldap:readwrite:pants

So basically ldap:readwrite:<nickname>.

Now, all keys are stored in the storage_dn folder. An example key:

# /desktop/gnome/file_views/icon_theme, GConf, gnome2, people, rietveld,
nl
dn:key=/desktop/gnome/file_views/icon_theme,cn=GConf,uid=gnome2,ou=people,dc=
 rietveld,dc=nl
objectClass: GConfKey
key: /desktop/gnome/file_views/icon_theme
type: string
value: default
mtime: 1042320535
muser: gnome2

I think that is pretty clear. Using this method we can let the LDAP
server filter out the keys we want (if we search on key=/desktop/gnome/*
for example), which is pretty cool. Also, I wrote a schema file, which
should be installed on the LDAP server for the LDAP backend to function
properly. It defines a GConfKey object class, and attributes like key,
type, value, etc.

I have a working implementation, I can run a gnome2 session which uses
the LDAP backend. Also, I can run gconf-editor in that session and
browse the keys without problems.

> 
> I haven't looked at this at all, mostly because I don't know much
> about LDAP. So it would be helpful to me (and probably to Kristian) to
> have third-party opinions on the best approach.
> 
> Kristian, btw you should post that patch to gconf-list and we should
> look at what it takes to get it merged.

The backend is far from ready, some points which I hope to work on soon:
* support for saving schemas/default settings in the LDAP server
* locale stuff (need to figure out what we need, etc).
* security/authentication needs work

That is purely for the backend, for gconfd we need:
* support for caching the keys, etc, when working offline. And synching
with the server when you come online again
* support for running multiple gconf daemons querying the LDAP server
for the same user. We probably need IPC between the daemons here.

This is all really interesting stuff, I hope I will have time to
continue working on it soon!

> 
> > I would think reading the LDAP server every time a gconf key was
> > requested would be a little bit of overload, possibly these will need to
> > be cached.

If the gconf daemon doesn't cache the keys, I can write caching support
in the LDAP backend. That's a trivial task.



	-Kris

> 
> Right, that's simple enough to do.
> 
> Havoc
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list