another update to the chapter 5 of the admin guide

This commit is contained in:
Jong Hyuk Choi 2003-11-24 23:18:06 +00:00
parent c204f4061f
commit 4eee5c8595

View File

@ -355,7 +355,7 @@ See the chapter entitled {{SECT:Replication with slurpd}} for more
information on how to use this directive. information on how to use this directive.
H4: rootdn <dn> H4: rootdn <DN>
This directive specifies the DN that is not subject to This directive specifies the DN that is not subject to
access control or administrative limit restrictions for access control or administrative limit restrictions for
@ -414,36 +414,6 @@ order they appear in the file. Thus, if one database suffix is a
prefix of another, it must appear after it in the config file. prefix of another, it must appear after it in the config file.
H4: updatedn <dn>
This directive is only applicable in a slave slapd. It specifies
the DN allowed to make changes to the replica. This may be the DN
{{slurpd}}(8) binds as when making changes to the replica or the DN
associated with a SASL identity.
Entry-based Example:
> updatedn "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
See the {{SECT:Replication with slurpd}} chapter for more information
on how to use this directive.
H4: updateref <URL>
This directive is only applicable in a slave slapd. It
specifies the URL to return to clients which submit update
requests upon the replica.
If specified multiple times, each {{TERM:URL}} is provided.
\Example:
> updateref ldap://master.example.net
H4: syncrepl H4: syncrepl
> syncrepl id=<replica ID> > syncrepl id=<replica ID>
@ -458,9 +428,9 @@ H4: syncrepl
> [sizelimit=<limit>] > [sizelimit=<limit>]
> [timelimit=<limit>] > [timelimit=<limit>]
> [schemachecking=on|off] > [schemachecking=on|off]
> [updatedn=<dn>] > [updatedn=<DN>]
> [bindmethod=simple|sasl] > [bindmethod=simple|sasl]
> [binddn=<dn>] > [binddn=<DN>]
> [saslmech=<mech>] > [saslmech=<mech>]
> [authcid=<identity>] > [authcid=<identity>]
> [authzid=<identity>] > [authzid=<identity>]
@ -468,57 +438,67 @@ H4: syncrepl
> [realm=<realm>] > [realm=<realm>]
> [secprops=<properties>] > [secprops=<properties>]
This directive specifies the current database as a replica of the This directive specifies the current database as a replica of the
master database at the provider site. The replica database at the master content by establishing the current {{slapd}}(8) as a
replication consumer site is kept up-to-date with the master database replication consumer site running a syncrepl replication engine.
using the LDAP Content Synchronization protocol. See The master database is located at the replication provider site
{{EX:draft-zeilenga-ldup-sync-xx.txt}} ({{a work in progress}}) for specified by the {{EX:provider}} parameter. The replica database is
more information on the protocol. kept up-to-date with the master content using the LDAP Content
Synchronization protocol. See {{EX:draft-zeilenga-ldup-sync-xx.txt}}
({{a work in progress}}) for more information on the protocol.
The {{EX:id}} parameter is used for identification of the current The {{EX:id}} parameter is used for identification of the current
syncrepl directive in the database, where the three-digit integer {{EX:syncrepl}} directive in the database, where {{EX:<replica ID>}}
{{EX:<replica ID>}} uniquely identifies the syncrepl specification uniquely identifies the syncrepl specification described by the current
described by the current syncrepl directive. {{EX:syncrepl}} directive. {{EX:<replica ID>}} is non-negative and is no
more than three digits in length.
The {{EX:provider}} parameter specifies the replication provider site The {{EX:provider}} parameter specifies the replication provider site
containing the master database as an LDAP URI. The {{EX:provider}} containing the master content as an LDAP URI. The {{EX:provider}}
parameter specifies a scheme, a host and optionally a port where the parameter specifies a scheme, a host and optionally a port where the
provider slapd instance can be found. Either a domain name or IP provider slapd instance can be found. Either a domain name or IP
address may be used for <hostname>. Examples are address may be used for <hostname>. Examples are
{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}. {{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
If <port> is not given, the standard LDAP port number (389 or 636) is used. If <port> is not given, the standard LDAP port number (389 or 636) is used.
Note that syncrepl uses a consumer-initiated protocol, and hence its Note that the syncrepl uses a consumer-initiated protocol, and hence its
specification is located at the consumer site, whereas the {{EX:replica}} specification is located at the consumer site, whereas the {{EX:replica}}
specification is located at the provider site. {{EX:syncrepl}} and specification is located at the provider site. {{EX:syncrepl}} and
{{EX:replica}} are two independent replication mechanisms and they do {{EX:replica}} directives define two independent replication
not represent the replication peers of each other. mechanisms. They do not represent the replication peers of each other.
The content of the {{EX:syncrepl}} replica is defined using a search The content of the syncrepl replica is defined using a search
specification as its result set. The consumer {{slapd}}(8) will specification as its result set. The consumer slapd will
send search requests to the provider slapd according to the search send search requests to the provider slapd according to the search
specification. The search specification includes {{EX:searchbase}}, specification. The search specification includes {{EX:searchbase}},
{{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}}, {{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
{{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal {{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
search specification. The {{EX:syncrepl}} search specification has search specification. The syncrepl search specification has
the same value syntax and the same default values as in the the same value syntax and the same default values as in the
{{ldapsearch}}(1) client search tool. {{ldapsearch}}(1) client search tool.
The LDAP Content Synchronization protocol has two operation The LDAP Content Synchronization protocol has two operation
types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}. types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
The operation type is specified by the {{EX:type}} parameter. The operation type is specified by the {{EX:type}} parameter.
In the {{EX:refreshOnly}} mode, the next synchronization search operation In the {{EX:refreshOnly}} operation, the next synchronization search operation
is periodically rescheduled at an interval time after each is periodically rescheduled at an interval time after each
synchronization operation finishes. The interval is specified synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default. by the {{EX:interval}} parameter. It is set to one day by default.
In the {{EX:refreshAndPersist}} mode, a synchronization search In the {{EX:refreshAndPersist}} operation, a synchronization search
remains persistent in the provider slapd. Further updates to the remains persistent in the provider slapd. Further updates to the
master replica will generate searchResultEntry to the consumer slapd master replica will generate {{EX:searchResultEntry}} to the consumer slapd
as the search responses to the persistent synchronization search. as the search responses to the persistent synchronization search.
The schema checking can be enforced at the LDAP Sync consumer site The schema checking can be enforced at the LDAP Sync consumer site
by turning on the {{EX:schemachecking}} parameter. The default is off. by turning on the {{EX:schemachecking}} parameter.
If it is turned on, every replicated entry will be checked for its
schema as the entry is stored into the replica content.
Every entry in the replica should contain those attributes
required by the schema definition.
If it is turned off, entries will be stored without checking
schema conformance. The default is off.
The {{EX:updatedn}} paramter specifies the DN in the consumer site The {{EX:updatedn}} parameter specifies the DN in the consumer site
which is allowed to make changes to the replica. This DN is used which is allowed to make changes to the replica. This DN is used
locally by the syncrepl engine when updating the replica with locally by the syncrepl engine when updating the replica with
the entries received from the provider site by using the the entries received from the provider site by using the
@ -561,6 +541,36 @@ See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
for more information on how to use this directive. for more information on how to use this directive.
H4: updatedn <DN>
This directive is only applicable in a slave slapd. It specifies
the DN allowed to make changes to the replica. This may be the DN
{{slurpd}}(8) binds as when making changes to the replica or the DN
associated with a SASL identity.
Entry-based Example:
> updatedn "cn=Update Daemon,dc=example,dc=com"
SASL-based Example:
> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
See the {{SECT:Replication with slurpd}} chapter for more information
on how to use this directive.
H4: updateref <URL>
This directive is only applicable in a slave slapd. It
specifies the URL to return to clients which submit update
requests upon the replica.
If specified multiple times, each {{TERM:URL}} is provided.
\Example:
> updateref ldap://master.example.net
H3: BDB Database Directives H3: BDB Database Directives
Directives in this category only apply to a {{TERM:BDB}} database. Directives in this category only apply to a {{TERM:BDB}} database.
@ -581,27 +591,28 @@ containing the database and associated indices live.
H4: sessionlog <sid> <limit> H4: sessionlog <sid> <limit>
This directive specifies a session log store in the provider site This directive specifies a session log store in the syncrepl
which contains the information on the entries which has been replication provider site which contains information on
scoped out of the content of the {{EX:<sid>}} replication session. 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 The first syncrepl search request having the same sid value in the
cookie establishes the session log store in the provider site. cookie establishes the session log store in the provider site.
The number of the entries in the session log store is limited The number of the entries in the session log store is limited
by {{EX:<limit>}}. Excessive entries are removed from the store by {{EX:<limit>}}. Excessive entries are removed from the store
in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are integers. in the FIFO order. Both {{EX:<sid>}} and {{EX:<limit>}} are
{{EX:<sid>}} has no more than three digits. non-negative integers. {{EX:<sid>}} has no more than three digits.
The LDAP Content Synchronization operation of a pre-existing The LDAP Content Synchronization operation that falls into a pre-existing
session uses the session log store in order to reduce the amount session uses the session log store in order to reduce the amount
of synchronization traffic. If the replica is not so outdated that 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, it can be made up-to-date by the information in the session store,
the provider slapd will send the in-scope entries added to or modified the provider slapd will send the consumer slapd the identities of the
within the replication content together with the identities of the scoped-out entries together with the in-scope entries added to or
scoped-out entries to the consumer slapd. If the replica status is modified within the replication content. If the replica status is
beyond the coverage of the history store, then the provider slapd will beyond the coverage of the history store, then the provider slapd will
send the changed in-scope entries together with the identities of the send the identities of the unchanged in-scope entries along with the
unchanged in-scope entries. The consumer slapd will then remove those changed in-scope entries. The consumer slapd will then remove those
entries in the replica which is not identified as present in the entries in the replica which are not identified as present in the
master content. master content.
An access control mechanism is to be further provided to An access control mechanism is to be further provided to