1 .TH SLAPO-DDS 5 "RELEASEDATE" "OpenLDAP LDVERSION"
2 .\" Copyright 2005-2006 The OpenLDAP Foundation, All Rights Reserved.
3 .\" Copying restrictions apply. See the COPYRIGHT file.
6 slapo-dds \- dds overlay
14 implements dynamic objects as per RFC 2589.
18 Dynamic Dyrectory Services.
19 It allows to define dynamic objects, characterized by the
22 Dynamic objects have a limited life, determined by a time-to-live (TTL)
23 that can be refreshed by means of a specific
26 This operation allows to set the Client Refresh Period (CRP),
27 namely the period between refreshes that is required to preserve the
28 dynamic object from expiration.
29 The expiration time is computed by adding the requested TTL to the
31 When dynamic objects reach the end of their life without being
32 further refreshed, they are automatically deleted; there is no guarantee
33 of immediate deletion, but clients should not count over it.
34 Dynamic objects can have subordinates, provided they also are dynamic
36 RFC 2589 does not specify what should the behavior of a dynamic
37 directory service be when a dynamic object with (dynamic) subordinates
39 In this implementation, the life of dynamic objects with subordinates
40 is prolonged until all the dynamic subordinates expired.
47 overlay to the current database:
55 overlay may be used with any backend that implements the
62 Since its use may result in many internal entry lookups, adds
63 and deletes, it should be best used in conjunction with backends
64 that have resonably good write performances.
67 The config directives that are specific to the
69 overlay are prefixed by
71 to avoid potential conflicts with directives specific to the underlying
72 database or to other stacked overlays.
75 .B dds\-max\-ttl <ttl>
76 Specifies the max TTL value; this is the default TTL newly created
77 dynamic objects receive, unless
80 When the client with a refresh exop requests a TTL higher than it,
81 sizeLimitExceeded is returned.
82 This value must be between 86400 (1 day, the default) and 31557600
83 (1 year plus 6 hours, as per RFC 2589).
86 .B dds\-min\-ttl <ttl>
87 Specifies the min TTL value; clients requesting a lower TTL by means
88 of the refresh exop actually obtain this value as CRP.
89 If set to 0 (the default), no lower limit is set.
92 .B dds\-default\-ttl <ttl>
93 Specifies the default TTL value that newly created dynamic objects get.
94 If set to 0 (the default), the
99 .B dds\-interval <ttl>
100 Specifies the interval between expiration checks; efaults to 1 hour.
103 .B dds\-tolerance <ttl>
104 Specifies an extra time that is added to the timer that actually wakes up
105 the thread that will delete an expired dynamic object.
106 So the nominal life of the entry is that specified in the
108 attribute, but its life will actually be
109 .BR " entryTtl + tolerance " .
110 Note that there is no guarantee that the life of a dynamic object will be
112 the requested TTL; due to implementation details, it may be longer, which
113 is allowed by RFC 2589.
114 By default, tolerance is 0.
117 .B dds\-max\-dynamicObjects <num>
118 Specifies the maximum number of dynamic objects that can simultaneously exist
119 within a naming context.
120 This allows to limit the amount of resources (mostly in terms of runqueue size)
121 that are used by dynamic objects.
122 By default, no limit is set.
125 .B dds-state {TRUE|false}
126 Specifies if the Dynamic Directory Services feature is enabled or not.
127 By default it is; however, a proxy does not need to keep track of dynamic
128 objects itself, it only needs to inform the frontend that support for
129 dynamic objects is available.
134 overlay restricts the refresh operation by requiring
140 for details about the
145 is an operational, NO-USER-MODIFICATION attribute, no direct write access
149 overlay turns refresh exops into an internal modification to the value
156 RFC 2589 recommends that anonymous clients should not be allowed to refresh
158 This cn be implemented by appropriately crafting access control to obtain
161 Example: restrict refresh to authenticated clients
165 access to attrs=entryTtl
171 Example: restrict refresh to the creator of the dynamic object
175 access to attrs=entryTtl
176 by dnattr=creatorsName manage
181 Another suggested usage of dynamic objects is to implement dynamic meetings;
182 in this case, all the participants to the meeting are allowed to refresh
183 the meeting object, but only the creator can delete it (otherwise it will
184 be deleted when the TTL expires)
186 Example: assuming \fIparticipant\fP is a valid DN-valued attribute,
187 allow users to start a meeting and to join it; restrict refresh
188 to the participants; restrict delete to the creator
192 access to dn.base="cn=Meetings"
196 access to dn.onelevel="cn=Meetings"
198 by dnattr=creatorsName write
201 access to dn.onelevel="cn=Meetings"
203 by dnattr=creatorsName write
207 access to dn.onelevel="cn=Meetings"
209 by dnattr=participant manage
216 This implementation of RFC 2589 provides a restricted interpretation of how
217 dynamic objects replicate. Only the master takes care of handling dynamic
218 object expiration, while replicas simply see the dynamic object as a plain
221 When using slurpd replication, one needs to explicitly exclude the
226 This implementation of RFC 2589 introduces a new operational attribute,
227 .BR entryExpireTimestamp ,
228 that contains the expiration timestamp. This must be excluded from
232 add the following \fIexclusion list\fP to each
239 attrs!=@dynamicObject,entryTtl,entryExpireTimestamp
243 When using syncrepl, the quick and dirty solution is to set
245 and, optionally, exclude the operational attributes from replication, using
250 exattrs=entryTtl,entryExpireTimestamp
254 In any case the overlay must be either statically built in or run-time loaded
255 by the consumer, so that it is aware of the
256 .B entryExpireTimestamp
257 operational attribute; however, it must not be configured in the shadow
259 Currently, there is no means to remove the
261 class from the entry; this may be seen as a feature, since it allows to see
262 the dynamic properties of the object.
267 default slapd configuration file
272 Implemented by Pierangelo Masarati.