.TH SLAPO-DDS 5 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" Copyright 2005-2007 The OpenLDAP Foundation, All Rights Reserved.
+.\" Copyright 2005-2012 The OpenLDAP Foundation, All Rights Reserved.
.\" Copying restrictions apply. See the COPYRIGHT file.
.\" $OpenLDAP$
.SH NAME
-slapo-dds \- dds overlay
+slapo\-dds \- Dynamic Directory Services overlay to slapd
.SH SYNOPSIS
ETCDIR/slapd.conf
.SH DESCRIPTION
The name
.B dds
stands for
-Dynamic Dyrectory Services.
+Dynamic Directory Services.
It allows to define dynamic objects, characterized by the
.B dynamicObject
objectClass.
-Dynamic objects have a limited life, determined by a time-to-live (TTL)
-that can be refreshed by means of a specific
+
+Dynamic objects have a limited lifetime, determined by a time-to-live
+(TTL) that can be refreshed by means of a specific
.B refresh
extended operation.
This operation allows to set the Client Refresh Period (CRP),
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 life without being
-further refreshed, they are automatically deleted; there is no guarantee
-of immediate deletion, but clients should not count over it.
-Dynamic objects can have subordinates, provided they also are dynamic
+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 should the behavior of a dynamic
-directory service be when a dynamic object with (dynamic) subordinates
+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 life of dynamic objects with subordinates
-is prolonged until all the dynamic subordinates expired.
+In this implementation, the lifetime of dynamic objects with subordinates
+is prolonged until all the dynamic subordinates expire.
This
.B overlay dds
.LP
-The
+The database must have a
+.B rootdn
+specified, otherwise, the
+.B dds
+overlay will not be able to delete expired objects. The
.B dds
overlay may be used with any backend that implements the
.BR add ,
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 resonably good write performances.
+that have reasonably good write performances.
.LP
The config directives that are specific to the
.TP
.B dds\-max\-ttl <ttl>
-Specifies the max TTL value; this is the default TTL newly created
+Specifies the max TTL value.
+This is also the default TTL newly created
dynamic objects receive, unless
.B dds\-default\-ttl
is set.
-When the client with a refresh exop requests a TTL higher than it,
-sizeLimitExceeded is returned.
+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).
.TP
.B dds\-min\-ttl <ttl>
Specifies the min TTL value; clients requesting a lower TTL by means
-of the refresh exop actually obtain this value as CRP.
+of the refresh extended operation actually obtain this value as CRP.
If set to 0 (the default), no lower limit is set.
.TP
.B 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 life of the entry is that specified in the
+So the nominal lifetime of the entry is that specified in the
.B entryTtl
-attribute, but its life will actually be
-.BR " entryTtl + tolerance " .
-Note that there is no guarantee that the life of a dynamic object will be
+attribute, but its lifetime will actually be
+.BR "entryTtl + tolerance" .
+Note that there is no guarantee that the lifetime of a dynamic object
+will be
.I exactly
the requested TTL; due to implementation details, it may be longer, which
is allowed by RFC 2589.
.B 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 runqueue size)
-that are used by dynamic objects.
+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.
.TP
-.B dds-state {TRUE|false}
+.B 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
to it is possible.
So the
.B dds
-overlay turns refresh exops into an internal modification to the value
-of the
+overlay turns refresh extended operation into an internal modification to
+the value of the
.B entryTtl
attribute with the
-.B manageDIT
+.B relax
control set.
RFC 2589 recommends that anonymous clients should not be allowed to refresh
a dynamic object.
-This cn be implemented by appropriately crafting access control to obtain
+This can be implemented by appropriately crafting access control to obtain
the desired effect.
Example: restrict refresh to authenticated clients
object expiration, while replicas simply see the dynamic object as a plain
object.
-When using slurpd replication, one needs to explicitly exclude the
+When replicating these objects, one needs to explicitly exclude the
.B dynamicObject
class and the
.B entryTtl
.BR entryExpireTimestamp ,
that contains the expiration timestamp. This must be excluded from
replication as well.
-In
-.BR slapd.conf (5),
-add the following \fIexclusion list\fP to each
-.B replica
-statement:
-
-.RS
-.nf
-replica ...
- attrs!=@dynamicObject,entryTtl,entryExpireTimestamp
-.fi
-.RE
-When using syncrepl, the quick and dirty solution is to set
+The quick and dirty solution is to set
.B schemacheck=off
+in the syncrepl configuration
and, optionally, exclude the operational attributes from replication, using
.RS
default slapd configuration file
.SH SEE ALSO
.BR slapd.conf (5),
+.BR slapd\-config (5),
.BR slapd (8).
.SH AUTHOR
Implemented by Pierangelo Masarati.
projects / openldap / blobdiff