|
|
Эта страница руководства для версии 10.9 Mac OS XЕсли Вы выполняете различную версию Mac OS X, просматриваете документацию локально:
Читать страницы руководстваСтраницы руководства предназначаются как справочник для людей, уже понимающих технологию.
|
SLAPO-DDS(5) SLAPO-DDS(5)
NAME
slapo-dds - Dynamic Directory Services overlay to slapd
SYNOPSIS
/etc/openldap/slapd.conf
DESCRIPTION
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 auto-matically automatically
matically 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 subor-dinates subordinates
dinates is prolonged until all the dynamic subordinates expire.
This slapd.conf(5) directive adds the dds overlay to the current database:
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 perfor-mances. performances.
mances.
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 used.
dds-interval <ttl>
Specifies the interval between expiration checks; defaults to 1 hour.
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 set.
dds-state {TRUE|false}
Specifies if the Dynamic Directory Services feature is enabled or not. By default it is; how-ever, however,
ever, 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.
ACCESS CONTROL
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 opera-tional, operational,
tional, 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"
attrs=children
by users write
access to dn.onelevel="cn=Meetings"
attrs=entry
by dnattr=creatorsName write
by * read
access to dn.onelevel="cn=Meetings"
attrs=participant
by dnattr=creatorsName write
by users selfwrite
by * read
access to dn.onelevel="cn=Meetings"
attrs=entryTtl
by dnattr=participant manage
by * read
REPLICATION
This implementation of RFC 2589 provides a restricted interpretation of how dynamic objects repli-cate. replicate.
cate. 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, entryEx-pireTimestamp, entryExpireTimestamp,
pireTimestamp, 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 ...
exattrs=entryTtl,entryExpireTimestamp
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 config-ured configured
ured 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.
FILES
/etc/openldap/slapd.conf
default slapd configuration file
SEE ALSO
slapd.conf(5), slapd-config(5), slapd(8).
AUTHOR
Implemented by Pierangelo Masarati.
OpenLDAP 2.4.28 2011/11/24 SLAPO-DDS(5)
|
Сообщение о проблемах
Способ сообщить о проблеме с этой страницей руководства зависит от типа проблемы:
- Ошибки содержания
- Ошибки отчета в содержании этой документации со ссылками на отзыв ниже.
- Отчеты об ошибках
- Сообщите об ошибках в функциональности описанного инструмента или API через Генератор отчетов Ошибки.
- Форматирование проблем
- Отчет, форматирующий ошибки в интерактивной версии этих страниц со ссылками на отзыв ниже.