Re: ACIs and OL 2.3, rfc ?

[Piotr Wadas <pwadas@jewish.org.pl>]

> 
> IMHO, the most appealing feature of ACIs is the fact that in principle access
> rules get replicated along with data.  However, the lack of a standard defeats
> this purpose when getting to cross-implementation replication, migration and
> so.  Moreover, one might want to have different access rules for different
> shadows of the same database. 
This probably breaks one of ACI principles - that an acl is stored "with 
the entry itself", as shadow probably means "the same entry shadowed", 
rather than "shadowed copy of an entry"(?). On the other hand, if ACI 
would have been designed with object-like manner, some attribute could 
keep a piece of information about a particular "shadow" it's effective 
with.

Currently I have a few openldapservers with common entries, and in some 
cases I replicate only needed branches, anyway, in some other, I rather 
prefer to add some (multi or single value) attribute like 
"thisEntryUsedByHost", replicate the whole tree, and on the application 
which uses particular replica, add some filter in 
&(thisEntryUsedByHost=my.current.host.name). I don't have any comparable
source of information, is something wrong with such usage?

> Finally, right now access control on OpenLDAP's slapd can be modified 
>without the need to stop and restart it, by means of cn=config; there is 
>work in progress to allow configuration replication.  As such, OpenLDAP 
>offers better means to achieve the same purpose without ACIs, with the 
>access determinism guaranteed by avoiding the use of ACIs.
That's ok, I just started using cn=config lately and I'm not familiar
with it, however, isn't there other side of penny - one can modify
config information without restarting, but modified information
is not stored/saved between restarts ? ACI is somehow "static", although
it's not "static" in common sense :)

Regards,
Piotr