SLAPO-DDS(5)							File Formats Manual						      SLAPO-DDS(5)

NAME

       slapo-dds - Dynamic Directory Services overlay to slapd

SYNOPSIS

       /etc/ldap/slapd.conf

DESCRIPTION

       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 dele-
       tion, 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:

       overlay dds

       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.

       dds-max-ttl <ttl>
	      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).

       dds-min-ttl <ttl>
	      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.

       dds-default-ttl <ttl>
	      Specifies the default TTL value that newly created dynamic objects get.  If set to 0 (the default), the dds-max-ttl is used.

       dds-interval <ttl>
	      Specifies the interval between expiration checks; defaults to 1 hour.

       dds-tolerance <ttl>
	      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 + toler-
	      ance.  Note that there is no guarantee that the lifetime of a dynamic object will be exactly the requested TTL; due  to  implementa-
	      tion details, it may be longer, which is allowed by RFC 2589.  By default, tolerance is 0.

       dds-max-dynamicObjects <num>
	      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.

       dds-state {TRUE|false}
	      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.

ACCESS CONTROL

       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 possi-
       ble.   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

       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)

       Example: assuming participant is a valid DN-valued attribute, allow users to start a meeting and to join it; restrict refresh to  the  par-
       ticipants; 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

REPLICATION

       This  implementation of RFC 2589 provides a restricted interpretation of how dynamic objects replicate.	Only the master takes care of han-
       dling 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 entryExpireTimes-
       tamp operational attribute; however, it must not be configured in the shadow database.  Currently, there is no means to remove the  dynami-
       cObject class from the entry; this may be seen as a feature, since it allows to see the dynamic properties of the object.

FILES

       /etc/ldap/slapd.conf
	      default slapd configuration file

SEE ALSO

       slapd.conf(5), slapd-config(5), slapd(8).

AUTHOR

       Implemented by Pierangelo Masarati.

OpenLDAP							    2012/04/23							      SLAPO-DDS(5)