The database must have a
rootdn specified, otherwise, the
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 write performances.
The config directives that are specific to the
dds overlay are prefixed by
dds-, to 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, unless
dds-default-ttl 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
dds-max-ttl is used.
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
exactly the requested TTL; due to implementation details, it may be longer, which
is allowed by RFC 2589.
By default, tolerance is 0.
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.
The dds overlay restricts the refresh operation by requiring manage access to the entryTtl attribute (see slapd.access(5) for details about the manage 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 of the entryTtl 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
Example: restrict refresh to the creator of the dynamic objectaccess to attrs=entryTtl by users 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)access to attrs=entryTtl by dnattr=creatorsName manage by * read
Example: assuming 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 exclude the dynamicObject class and the entryTtl attribute. This implementation of RFC 2589 introduces a new operational attribute, entryExpireTimestamp, that 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 the entryExpireTimestamp operational attribute; however, it must not be configured in the shadow database. Currently, there is no means to remove the dynamicObject class from the entry; this may be seen as a feature, since it allows to see the dynamic properties of the object.
/usr/local/etc/openldap/slapd.conf default slapd configuration file
Implemented by Pierangelo Masarati.
|OpenLDAP 2.4.44||SLAPO-DDS (5)||2016/02/05|