Man Linux: Main Page and Category List


       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.