slapo−dds — Dynamic Directory Services overlay to slapd
to slapd(8) implements dynamic
objects as per RFC 2589. The name
dds stands for Dynamic
Directory Services. It allows to define dynamic objects,
characterized by the
Dynamic objects have a limited lifetime, determined by a
time-to-live (TTL) that can be refreshed by means of a
extended operation. This operation allows to set the Client
Refresh Period (CRP), namely the period between refreshes
that is required to preserve the dynamic object from
expiration. The expiration time is computed by adding the
requested TTL to the current time. 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.
This slapd.conf(5) directive
overlay to the current database:
The database must have a
dds overlay will not be
able to delete expired objects. The
dds overlay may be used
with any backend that implements the
Since its use may result in many internal entry
lookups, adds and deletes, it should be best used in
conjunction with backends that have reasonably good
The config directives that are specific to the
dds overlay are prefixed by
avoid potential conflicts with directives specific to the
underlying database or to other stacked overlays.
Specifies the max TTL value. This is also the
default TTL newly created dynamic objects receive,
is set. When the client with a refresh extended
operation requests a TTL higher than it,
sizeLimitExceeded is returned. This value must be
between 86400 (1 day, the default) and 31557600 (1 year
plus 6 hours, as per RFC 2589).
Specifies the min TTL value; clients requesting a lower TTL by means of the refresh extended operation actually obtain this value as CRP. If set to 0 (the default), no lower limit is set.
Specifies the default TTL value that newly created
dynamic objects get. If set to 0 (the default), the
Specifies the interval between expiration checks; defaults to 1 hour.
Specifies an extra time that is added to the timer
that actually wakes up the thread that will delete an
expired dynamic object. So the nominal lifetime of the
entry is that specified in the
entryTtl attribute, but
its lifetime will actually be entryTtl + tolerance. Note
that there is no guarantee that the lifetime of a
dynamic object will be
exactly the requested
TTL; due to implementation details, it may be longer,
which is allowed by RFC 2589. By default, tolerance is
Specifies the maximum number of dynamic objects that can simultaneously exist within a naming context. This allows to limit the amount of resources (mostly in terms of run-queue size) that are used by dynamic objects. By default, no limit is set.
Specifies if the Dynamic Directory Services feature is enabled or not. By default it is; however, a proxy does not need to keep track of dynamic objects itself, it only needs to inform the frontend that support for dynamic objects is available.
restricts the refresh operation by requiring
manage access to the
(see slapd.access(5) for details
access privilege). Since the
entryTtl is an operational,
NO-USER-MODIFICATION attribute, no direct write access to it
is possible. So the
dds overlay turns refresh
extended operation into an internal modification to the value
attribute with the
relax control set.
RFC 2589 recommends that anonymous clients should not be allowed to refresh a dynamic object. This can be implemented by appropriately crafting access control to obtain the desired effect.
Example: restrict refresh to authenticated clients
access to attrs=entryTtl by users manage by * read
Example: restrict refresh to the creator of the dynamic object
access to attrs=entryTtl by dnattr=creatorsName manage by * read
Another suggested usage of dynamic objects is to 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)
participant is a valid
DN-valued attribute, allow users to start a meeting and to
join it; restrict refresh to the participants; restrict
delete to the creator
access to dn.base="cn=Meetings" attrs=children by users write access to dn.onelevel="cn=Meetings" attrs=entry by dnattr=creatorsName write by * read access to dn.onelevel="cn=Meetings" attrs=participant by dnattr=creatorsName write by users selfwrite by * read access to dn.onelevel="cn=Meetings" attrs=entryTtl by dnattr=participant manage by * read
This implementation of RFC 2589 provides a restricted interpretation of how dynamic objects replicate. Only the master takes care of handling dynamic object expiration, while replicas simply see the dynamic object as a plain object.
When replicating these objects, one needs to explicitly
dynamicObject class and the
This implementation of RFC 2589 introduces a new operational
contains the expiration timestamp. This must be excluded from
replication as well.
The quick and dirty solution is to set
schemacheck=off in the
syncrepl configuration and, optionally, exclude the
operational attributes from replication, using
syncrepl ... exattrs=entryTtl,entryExpireTimestamp
In any case the overlay must be either statically built in
or run-time loaded by the consumer, so that it is aware of
operational attribute; however, it must not be configured in
the shadow database. Currently, there is no means to remove
class from the entry; this may be seen as a feature, since it
allows to see the dynamic properties of the object.