Provided by: slapd_2.4.28-1.1ubuntu4_i386 bug


       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

       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

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

       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 +
              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 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

       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.


       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

       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
       participants; restrict delete to the creator

              access to dn.base="cn=Meetings"
                   by users write

              access to dn.onelevel="cn=Meetings"
                   by dnattr=creatorsName write
                   by * read

              access to dn.onelevel="cn=Meetings"
                   by dnattr=creatorsName write
                   by users selfwrite
                   by * read

              access to dn.onelevel="cn=Meetings"
                   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 ...

       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.


              default slapd configuration file


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


       Implemented by Pierangelo Masarati.