URI such as {{EX:ldap://slave.example.com:389}} or
{{EX:ldaps://slave.example.com:636}}.
-The {{EX:binddn=}} parameter gives the DN to bind as for updates to
-the slave slapd. It should be a DN which has read/write
-access to the slave slapd's database, typically given as a
-{{EX:rootdn}} in the slave's config file. It must also match the
-{{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
-likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
-string should be enclosed in double quotes.
+The {{EX:binddn=}} parameter gives the DN to bind as for updates
+to the slave slapd. It should be a DN which has read/write access
+to the slave slapd's database. It must also match the {{EX:updatedn}}
+directive in the slave slapd's config file. Generally, this DN
+{{should not}} be the same as the {{EX:rootdn}} of the master
+database. Since DNs are likely to contain embedded spaces, the
+entire {{EX:"binddn=<DN>"}} string should be enclosed in double
+quotes.
The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
depending on whether simple password-based authentication or Kerberos
({{a work in progress}}) for more information on the protocol.
The {{EX:rid}} parameter is used for identification of the current
-{{EX:syncrepl}} directive within the replication consumer site,
+{{EX:syncrepl}} directive within the replication consumer server,
where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
-is non-negative and is no more than three digits in length.
+is non-negative and is no more than three decimal digits in length.
The {{EX:provider}} parameter specifies the replication provider site
containing the master content as an LDAP URI. The {{EX:provider}}
The {{EX:updatedn}} parameter specifies the DN in the consumer site
which is allowed to make changes to the replica. This DN is used
-locally by the syncrepl engine when updating the replica with
-the entries received from the provider site by using the
-internal operation mechanism. The update of the replica content
-is subject to the access control privileges of the DN.
-The DN should have read/write access to the replica database.
-It is typically given as a {{EX:rootdn}} in the consumer site's
-config file.
+locally by the syncrepl engine when updating the replica with the
+entries received from the provider site by using the internal
+operation mechanism. The update of the replica content is subject
+to the access control privileges of the DN. The DN should have
+read/write access to the replica database. Generally, this DN
+{{should not}} be the same as {{EX:rootdn}}.
The {{EX:binddn}} parameter gives the DN to bind as for the
syncrepl searches to the provider slapd. It should be a DN
H4: sessionlog <sid> <limit>
This directive specifies a session log store in the syncrepl
-replication provider site which contains information on
-the entries that have been scoped out of the content of the
-replication session identified by {{EX:<sid>}}.
-The first syncrepl search request having the same sid value in the
-cookie establishes the session log store in the provider site.
+replication provider server which contains information on
+the entries that have been scoped out of the replication
+content identified by {{EX:<sid>}}.
+The first syncrepl search request having the same {{EX:<sid>}} value
+in the cookie establishes the session log store in the provider server.
The number of the entries in the session log store is limited
by {{EX:<limit>}}. Excessive entries are removed from the store
in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are
-non-negative integers. {{EX:<sid>}} has no more than three digits.
+non-negative integers. {{EX:<sid>}} has no more than three decimal digits.
The LDAP Content Synchronization operation that falls into a pre-existing
-session uses the session log store in order to reduce the amount
+session can use the session log store in order to reduce the amount
of synchronization traffic. If the replica is not so outdated that
it can be made up-to-date by the information in the session store,
the provider slapd will send the consumer slapd the identities of the
scoped-out entries together with the in-scope entries added to or
modified within the replication content. If the replica status is
-beyond the coverage of the history store, then the provider slapd will
-send the identities of the unchanged in-scope entries along with the
-changed in-scope entries. The consumer slapd will then remove those
-entries in the replica which are not identified as present in the
-master content.
-
-An access control mechanism is to be further provided to
-make the session joining controllable.
+outdated too much and beyond the coverage of the history store,
+then the provider slapd will send the identities of the unchanged
+in-scope entries along with the changed in-scope entries.
+The consumer slapd will then remove those entries in the replica
+which are not identified as present in the provider content.
H3: LDBM Database Directives
> [aci=<attrname>]
> <access> ::= [self]{<level>|<priv>}
> <level> ::= none | auth | compare | search | read | write
-> <priv> ::= {=|+|-}{w|r|s|c|x}+
+> <priv> ::= {=|+|-}{w|r|s|c|x|0}+
> <control> ::= [stop | continue | break]
where the <what> part selects the entries and/or attributes to which
commonly selected in two ways: by DN and by filter. The following
qualifiers select entries by DN:
-> by *
-> by dn[.<basic-style>]=<regex>
-> by dn.<scope-style>=<DN>
+> to *
+> to dn[.<basic-style>]=<regex>
+> to dn.<scope-style>=<DN>
The first form is used to select all entries. The second form may
be used to select entries by matching a regular expression against
Entries may also be selected using a filter:
-> by filter=<ldap filter>
+> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
search filter, as described in {{REF:RFC2254}}. For example:
-> by filter=(objectClass=person)
+> to filter=(objectClass=person)
Note that entries may be selected by both DN and filter by
including both qualifiers in the <what> clause.
-> by dn.one="ou=people,o=suffix" filter=(objectClass=person)
+> to dn.one="ou=people,o=suffix" filter=(objectClass=person)
Attributes within an entry are selected by including a comma-separated
list of attribute names in the <what> selector:
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
title="Table 5.4: Access Levels"
Level Privileges Description
-none no access
+none =0 no access
auth =x needed to bind
compare =cx needed to compare
search =scx needed to apply search filters
H3: Access Control Examples
-The access control facility described above is quite powerful.
-This section shows some examples of its use. First, some
-simple examples:
+The access control facility described above is quite powerful. This
+section shows some examples of its use for descriptive purposes.
+
+A simple example:
> access to * by * read
client has not establish sufficient security protections, the
implicit {{EX:by * none}} clause would be applied.
-The following example shows the use of a style specifiers
-to select the entries by DN in two access directives where
-ordering is significant.
+The following example shows the use of a style specifiers to select
+the entries by DN in two access directives where ordering is
+significant.
> access to dn.children="dc=example,dc=com"
> by * search
> access to dn.subtree="dc=example,dc=com" attr=homePhone
> by self write
> by dn.children=dc=example,dc=com" search
-> by peername=IP:10\..+ read
+> by peername.regex=IP:10\..+ read
> access to dn.subtree="dc=example,dc=com"
> by self write
> by dn.children="dc=example,dc=com" search
projects / openldap / blobdiff