[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: back-config again

> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@stanford.edu]

> > There are still some issues regarding order-dependent
> config info (like
> > ACLs, sasl-regexp, database order). I have an idea to use attribute
> > tagging to help out here, e.g.:
>
> I tend to believe that ACLs should not be in back-config at all, but
> something more like back-access.  ACLs are not tied to
> database types or
> quantity (bdb, monitor, hdb, etc), and aren't exactly
> configuration pieces
> for the slapd process (or slurpd, or syncrepl).  They can
> also be quite
> fluid... I change my seperated out ACL file 20-30 times more
> often than I
> ever touch the slapd configuration.  Pulling it out into a different
> backend would more clearly distinguish that these are very
> different pieces
> of the LDAP server.

I see your point, but just because ACLs can be quite fluid doesn't make them
inherently different from the other configuration items. Replication
agreements can be relatively fluid too, particularly when you're first
experimenting with getting them set up. I personally like being able to
add/delete back-ldap instances on the fly, with each instance being a chunk
of a glued DIT. I.e., realtime control of knowledge references in a true
distributed directory. This is something we already do in Connexitor EMS, but
(I feel) is sorely lacking in OpenLDAP.

While we're thinking about ACLs, it would make sense to structure them
hierarchically instead of in a flat list. The current structure is a bit
silly if you have 40 different non-intersecting dn.subtree rules, because
they all still have to be checked even though maybe only one of them applies.
If ACLs were structured in a way that paralleled the actual hierarchy of the
DIT, a lot of extraneous checks could be eliminated.

Of course, if you're going to duplicate the DIT's hierarchical layout anyway,
you might as well just merge the ACLs into the DIT itself. Oh wait, that's an
ACI. Hm, what does *that* mean, I wonder....

Following any of these suggested changes to their logical *conclusion* means
making a lot of far-reaching, fundamental changes to the structure of the
server. For the moment, I'm content with only going one or two steps down
each path, and not pursuing them to their ultimate conclusion.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support