mirror/openldap
2
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-01-30 13:30:57 +08:00
Code Issues Packages Projects Releases Wiki Activity

DDS Docs complete.

Browse Source
This commit is contained in:
Gavin Henry 2008-03-06 17:05:55 +00:00
parent d56d6887f4
commit 9b1498d3e3
2 changed files with 1401 additions and 1343 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2696
doc/guide/admin/aspell.en.pws
View File

File diff suppressed because it is too large Load Diff

48
doc/guide/admin/overlays.sdf
View File

@ -347,7 +347,7 @@ H2: Dynamic Directory Services
H3: Overview
The {{dds}} overlay to {{slapd}}(8) implements dynamic objects as per RFC 2589.
The {{dds}} overlay to {{slapd}}(8) implements dynamic objects as per {{REF:RFC2589}}.
The name {{dds}} stands for Dynamic Directory Services. It allows to define
dynamic objects, characterized by the {{dynamicObject}} objectClass.
@ -362,62 +362,70 @@ deletion, so clients should not count on it.
H3: Dynamic Directory Service Configuration
A usage of dynamic objects might beto implement dynamic meetings; in this case,
A usage of dynamic objects might be 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).
If we add the overlay to an example database, specifying a Max TTL of 1 day, a
min of 10 seconds, with a default TTL of 1 hour. We'll also specify an interval
of 5 seconds between expiration checks and a tolerance of 1 second (lifetime of
a dynamic object will be {{B:entryTtl + tolerance}}.
of 120 (less than 60s might be too small) seconds between expiration checks and a
tolerance of 5 second (lifetime of a dynamic object will be {{entryTtl + tolerance}}).
> overlay dds
> dds-max-ttl 1d
> dds-min-ttl 10s
> dds-default-ttl 1h
> dds-interval 5s
> dds-tolerance 1s
> dds-interval 120s
> dds-tolerance 5s
So let's create an entry using:
and add an index:
> dn: cn=Dynamic,dc=example,dc=com
> objectClass: inetOrgPerson
> entryExpireTimestamp
Create a meeting is as simple as adding the following:
> dn: cn=OpenLDAP Documentation Meeting,ou=Meetings,dc=example,dc=com
> objectClass: groupOfNames
> objectClass: dynamicObject
> cn: Dynamic Object
> sn: Object
MORE coming.
> cn: OpenLDAP Documentation Meeting
> member: uid=ghenry,ou=People,dc=example,dc=com
> member: uid=hyc,ou=People,dc=example,dc=com
H4: Dynamic Directory Service ACLs
Allow users to start a meeting and to join it; restrict refresh to the {{B:member}}s;
Allow users to start a meeting and to join it; restrict refresh to the {{member}};
restrict delete to the creator:
> access to attrs=userPassword
> by self write
> by * read
>
> access to dn.base="cn=Meetings,dc=example,dc=com"
> access to dn.base="ou=Meetings,dc=example,dc=com"
> attrs=children
> by users write
>
> access to dn.onelevel="cn=Meetings,dc=example,dc=com"
> access to dn.onelevel="ou=Meetings,dc=example,dc=com"
> attrs=entry
> by dnattr=creatorsName write
> by * read
>
> access to dn.onelevel="cn=Meetings,dc=example,dc=com"
> access to dn.onelevel="ou=Meetings,dc=example,dc=com"
> attrs=participant
> by dnattr=creatorsName write
> by users selfwrite
> by * read
>
> access to dn.onelevel="cn=Meetings,dc=example,dc=com"
> access to dn.onelevel="ou=Meetings,dc=example,dc=com"
> attrs=entryTtl
> by dnattr=member manage
> by * read
In simple terms, the user who created the {{OpenLDAP Documentation Meeting}} can add new attendees,
refresh the meeting using (basically complete control):
> ldapexop -x -H ldap://ldaphost "refresh" "cn=OpenLDAP Documentation Meeting,ou=Meetings,dc=example,dc=com" "120" -D "uid=ghenry,ou=People,dc=example,dc=com" -W
Any user can join the meeting, but not add another attendee, but they can refresh the meeting. The ACLs above are quite straight forward to understand.
H2: Dynamic Groups
@ -907,7 +915,7 @@ H3: Overview
Overlays can be stacked, which means that more than one overlay
can be instantiated for each database, or for the frontend.
As a consequence, each overlay's function is called, if defined,
As a consequence, each overlays function is called, if defined,
when overlay execution is invoked.
Multiple overlays are executed in reverse order (it's a stack, all in all)
with respect to their definition in slapd.conf (5), or with respect