Delta-syncrepl is not supported yet with mirror mode.

[openldap] / doc / guide / admin / overlays.sdf

diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf
index 98bbfbf63b7523dab26888610325796660173693..e12f5d732ba90536036708f8d0a530e17d233f95 100644 (file)
--- a/doc/guide/admin/overlays.sdf
+++ b/doc/guide/admin/overlays.sdf
@@ -261,7 +261,7 @@ bound to the slave will also exist on the master. If that DN does not have
 update privileges on the master, nothing will happen.
 
 You will need to restart the slave after these changes. Then, if you are using 
-{{loglevel 256}}, you can monitor an {{ldapmodify}} on the slave and the master.
+{{loglevel stats}} (256), you can monitor an {{ldapmodify}} on the slave and the master.
 
 Now start an {{ldapmodify}} on the slave and watch the logs. You should expect 
 something like:
@@ -360,14 +360,64 @@ When dynamic objects reach the end of their lifetime without being further
 refreshed, they are automatically {{deleted}}. There is no guarantee of immediate 
 deletion, so clients should not count on it.
 
-Dynamic objects can have subordinates, provided these also are dynamic objects.
-RFC 2589 does not specify what the behavior of a dynamic directory service 
-should be when a dynamic object with (dynamic) subordinates expires.
-In this implementation, the lifetime of dynamic objects with subordinates is prolonged
-until all the dynamic subordinates expire.
-   
 H3: Dynamic Directory Service Configuration
 
+A usage of dynamic objects might beto implement dynamic meetings; in this case, 
+all the participants to the meeting are allowed to refresh the meeting object, 
+but only the creator can delete it (otherwise it will be deleted when the TTL expires).
+
+If we add the overlay to an example database, specifying a Max TTL of 1 day, a 
+min of 10 seconds, with a default TTL of 1 hour. We'll also specify an interval
+of 5 seconds between expiration checks and a tolerance of 1 second (lifetime of
+a dynamic object will be {{B:entryTtl + tolerance}}.
+
+>       overlay dds
+>       dds-max-ttl     1d
+>       dds-min-ttl     10s
+>       dds-default-ttl 1h
+>       dds-interval    5s
+>       dds-tolerance   1s
+
+So let's create an entry using:
+
+>       dn: cn=Dynamic,dc=example,dc=com
+>       objectClass: inetOrgPerson
+>       objectClass: dynamicObject
+>       cn: Dynamic Object
+>       sn: Object
+
+MORE coming.
+
+
+H4: Dynamic Directory Service ACLs
+
+Allow users to start a meeting and to join it; restrict refresh to the {{B:member}}s; 
+restrict delete to the creator:
+
+>       access to attrs=userPassword
+>          by self write
+>          by * read
+>       
+>       access to dn.base="cn=Meetings,dc=example,dc=com"
+>                 attrs=children
+>            by users write
+>       
+>       access to dn.onelevel="cn=Meetings,dc=example,dc=com"
+>                 attrs=entry
+>            by dnattr=creatorsName write
+>            by * read
+>       
+>       access to dn.onelevel="cn=Meetings,dc=example,dc=com"
+>                 attrs=participant
+>            by dnattr=creatorsName write
+>            by users selfwrite
+>            by * read
+>       
+>       access to dn.onelevel="cn=Meetings,dc=example,dc=com"
+>                 attrs=entryTtl
+>            by dnattr=member manage
+>            by * read
+
 
 H2: Dynamic Groups
 
@@ -855,6 +905,14 @@ H2: Overlay Stacking
 
 H3: Overview
 
+Overlays can be stacked, which means that more than one overlay
+can be instantiated for each database, or for the frontend.
+As a consequence, each overlay's function is called, if defined,
+when overlay execution is invoked.
+Multiple overlays are executed in reverse order (it's a stack, all in all)
+with respect to their definition in slapd.conf (5), or with respect
+to their ordering in the config database, as documented in slapd-config (5).
+
 
 H3: Example Scenarios