|SLAPO-DDS(5)||File Formats Manual||SLAPO-DDS(5)|
slapo-dds - Dynamic Directory Services overlay to slapd
The dds overlay 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 dynamicObject objectClass.
Dynamic objects have a limited lifetime, determined by a time-to-live (TTL) that can be refreshed by means of a specific refresh 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 adds the dds overlay to the current database:
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 add, modify, search, and delete operations. 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.
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
access to attrs=entryTtl by users manage by * read
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.
slapd.conf(5), slapd-config(5), slapd(8).
Implemented by Pierangelo Masarati.