mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2024-12-21 03:10:25 +08:00
Code Issues Packages Projects Releases Wiki Activity

Fix some formatting, phrasing, typos

Browse Source
This commit is contained in:
Hallvard Furuseth 2007-07-24 16:58:40 +00:00
parent b514b25795
commit 9d57146b7e
1 changed files with 30 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
doc/man/man5/slapo-dds.5
View File

@ -3,7 +3,7 @@
.\" Copying restrictions apply. See the COPYRIGHT file.
.\" $OpenLDAP$
.SH NAME
slapo-dds \- dds overlay
slapo-dds \- Dynamic Directory Services overlay
.SH SYNOPSIS
ETCDIR/slapd.conf
.SH DESCRIPTION
@ -15,12 +15,13 @@ implements dynamic objects as per RFC 2589.
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),
@ -28,16 +29,18 @@ 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 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
@ -61,7 +64,7 @@ and
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
@ -73,19 +76,20 @@ database or to other stacked overlays.
.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
@ -103,11 +107,12 @@ Specifies the interval between expiration checks; defaults to 1 hour.
.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
attribute, but its lifetime will actually be
.BR "entryTtl + tolerance" .
Note that there is no guarantee that the life of a dynamic object will be
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.
@ -117,8 +122,8 @@ By default, tolerance is 0.
.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
@ -146,8 +151,8 @@ is an operational, NO-USER-MODIFICATION attribute, no direct write access
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