[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
OpenLDAP enhancements
Hello-
I would like to make some changes to OpenLDAP, and I'd like some
feedback on my planned enhancements and my approach.
The basic idea is to expose the Schema and ACLs via LDAP, and
eventually to allow these configs to be changed via LDAP. I think
that this would be a very useful feature for sites that need to
delegate management of an LDAP server to multiple people. This would
also allow programmatic (and dynamic) changes to the schema and ACLs
(other than editing the conf files and restarting slapd).
There are a few ways to do this while limiting the amount of code
that needs to be changed in slapd. In fact, one primary goal would
be to make these enhancements without modifying the existing source.
My idea about doing this is to make a new backend that looks at
internal lists and structures within slapd, and then present these as
entities in the directory (and eventually modifies the internal
lists, too).
Another way to so this is to change acl_parse.c, etc. to read from
"the directory". In other words, schema and acl info would be
accessed through backend.c, as real objects in the directory, stored
wherever the (now minimal) conf file specified. This would require
mods to existing code, but would be more flexible than writing a
"slapd.conf" backend. (One benefit, for example, is that you could
have a schema/acl server for a bunch of distributed LDAP servers, and
you'd only have to maintain one "master" schema/acl by using the ldap
backend as the source for your schema/acl).
If the schema and acls are to be part of an LDAP directory, then
where would they go? What would their DNs look like, and what
attributes would they have? How would you manage global vs.
backend-specific acls? Would you maintain the order in which acls
are applied, or change the rules from first-match to a big OR of all
acls? I have a few thoughts on how to do this, but I want to hear
back from anyone about the concept of directory-based schema/ACLs
first.
Thanks for any comments,
Mark Valence