• Last 5 Forum Topics
    Last post

The Web Only This Site



  • MARC

    Mailing list ARChives
    - Search by -


    Computing Dictionary

  • Text Link Ads

  • LINUX man pages
  • Linux Man Page Viewer

    The following form allows you to view linux man pages.







           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) subor-
           dinates  expires.   In  this  implementation,  the  lifetime of dynamic
           objects with subordinates is prolonged until all the  dynamic  subordi-
           nates 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
           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 simul-
                  taneously 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.


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

  • Linux

    The Distributions


    The Software


    The News


  • Toll Free
Copyright © 1999 - 2016 by LinuxGuruz