Commit 21eef84a authored by Quanah Gibson-Mount's avatar Quanah Gibson-Mount
Browse files

ITS#9275 -- Update wording to remove slave and master terms, consolidate on provider/consumer

parent 24b45f57
Pipeline #573 passed with stage
in 29 minutes and 29 seconds
......@@ -84,8 +84,7 @@ Currently simple and kerberos-based authentication, are supported.
To use LDAP and still have reasonable security in a networked,
Internet/Intranet environment, secure shell can be used to setup
secure, encrypted connections between client machines and the LDAP
server, and between the LDAP server and any replica or slave servers
that might be used.
server, and between all LDAP nodes that might be used.
To perform the LDAP "bind" operation:
......
......@@ -60,7 +60,7 @@ attribute is updated on each successful bind operation.
.B lastbind_forward_updates
Specify that updates of the authTimestamp attribute
on a consumer should be forwarded
to a master instead of being written directly into the consumer's local
to a provider instead of being written directly into the consumer's local
database. This setting is only useful on a replication consumer, and
also requires the
.B updateref
......
......@@ -69,7 +69,7 @@ sdf-img: \
intro_tree.png \
ldap-sync-refreshandpersist.png \
ldap-sync-refreshonly.png \
n-way-multi-master.png \
n-way-multi-provider.png \
push-based-complete.png \
push-based-standalone.png \
refint.png \
......
......@@ -45,9 +45,9 @@ H2: Replicated Directory Service
slapd(8) includes support for {{LDAP Sync}}-based replication, called
{{syncrepl}}, which may be used to maintain shadow copies of directory
information on multiple directory servers. In its most basic
configuration, the {{master}} is a syncrepl provider and one or more
{{slave}} (or {{shadow}}) are syncrepl consumers. An example
master-slave configuration is shown in figure 3.3. Multi-Master
configuration, the {{provider}} is a syncrepl provider and one or more
{{consumer}} (or {{shadow}}) are syncrepl consumers. An example
provider-consumer configuration is shown in figure 3.3. Multi-Provider
configurations are also supported.
!import "config_repl.png"; align="center"; title="Replicated Directory Services"
......
......@@ -33,7 +33,7 @@ tuned to give quick response to high-volume lookup or search
operations. They may have the ability to replicate information
widely in order to increase availability and reliability, while
reducing response time. When directory information is replicated,
temporary inconsistencies between the replicas may be okay, as long
temporary inconsistencies between the consumers may be okay, as long
as inconsistencies are resolved in a timely manner.
There are many different ways to provide a directory service.
......@@ -430,11 +430,11 @@ a pool of threads. This reduces the amount of system overhead
required while providing high performance.
{{B:Replication}}: {{slapd}} can be configured to maintain shadow
copies of directory information. This {{single-master/multiple-slave}}
copies of directory information. This {{single-provider/multiple-consumer}}
replication scheme is vital in high-volume environments where a
single {{slapd}} installation just doesn't provide the necessary availability
or reliability. For extremely demanding environments where a
single point of failure is not acceptable, {{multi-master}} replication
single point of failure is not acceptable, {{multi-provider}} replication
is also available. {{slapd}} includes support for {{LDAP Sync}}-based
replication.
......
......@@ -87,7 +87,7 @@ type are:
.{{S: }}
+{{B: Start the server}}
Obviously this doesn't cater for any complicated deployments like {{SECT: MirrorMode}} or {{SECT: N-Way Multi-Master}},
Obviously this doesn't cater for any complicated deployments like {{SECT: MirrorMode}} or {{SECT: N-Way Multi-Provider}},
but following the above sections and using either commercial support or community support should help. Also check the
{{SECT: Troubleshooting}} section.
......
......@@ -79,7 +79,7 @@ or in raw form.
It is also used for {{SECT:delta-syncrepl replication}}
Note: An accesslog database is unique to a given master. It should
Note: An accesslog database is unique to a given provider. It should
never be replicated.
H3: Access Logging Configuration
......@@ -255,13 +255,13 @@ default when {{B:--enable-ldap}}.
H3: Chaining Configuration
In order to demonstrate how this overlay works, we shall discuss a typical
scenario which might be one master server and three Syncrepl slaves.
scenario which might be one provider server and three Syncrepl replicas.
On each replica, add this near the top of the {{slapd.conf}}(5) file
(global), before any database definitions:
> overlay chain
> chain-uri "ldap://ldapmaster.example.com"
> chain-uri "ldap://ldapprovider.example.com"
> chain-idassert-bind bindmethod="simple"
> binddn="cn=Manager,dc=example,dc=com"
> credentials="<secret>"
......@@ -271,48 +271,48 @@ On each replica, add this near the top of the {{slapd.conf}}(5) file
Add this below your {{syncrepl}} statement:
> updateref "ldap://ldapmaster.example.com/"
> updateref "ldap://ldapprovider.example.com/"
The {{B:chain-tls}} statement enables TLS from the slave to the ldap master.
The {{B:chain-tls}} statement enables TLS from the replica to the ldap provider.
The DITs are exactly the same between these machines, therefore whatever user
bound to the slave will also exist on the master. If that DN does not have
update privileges on the master, nothing will happen.
bound to the replica will also exist on the provider. If that DN does not have
update privileges on the provider, nothing will happen.
You will need to restart the slave after these {{slapd.conf}} changes.
You will need to restart the replica after these {{slapd.conf}} changes.
Then, if you are using {{loglevel stats}} (256), you can monitor an
{{ldapmodify}} on the slave and the master. (If you're using {{cn=config}}
{{ldapmodify}} on the replica and the provider. (If you're using {{cn=config}}
no restart is required.)
Now start an {{ldapmodify}} on the slave and watch the logs. You should expect
Now start an {{ldapmodify}} on the replica and watch the logs. You should expect
something like:
> Sep 6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 ACCEPT from IP=143.199.102.216:45181 (IP=143.199.102.216:389)
> Sep 6 09:27:25 slave1 slapd[29274]: conn=11 op=0 STARTTLS
> Sep 6 09:27:25 slave1 slapd[29274]: conn=11 op=0 RESULT oid= err=0 text=
> Sep 6 09:27:25 slave1 slapd[29274]: conn=11 fd=31 TLS established tls_ssf=256 ssf=256
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=people,dc=example,dc=com" method=128
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=1 RESULT tag=97 err=0 text=
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD dn="uid=user1,ou=People,dc=example,dc=com"
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 MOD attr=mail
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=2 RESULT tag=103 err=0 text=
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 op=3 UNBIND
> Sep 6 09:27:28 slave1 slapd[29274]: conn=11 fd=31 closed
> Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
> Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_search (0)
> Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: uid=user1,ou=People,dc=example,dc=com
> Sep 6 09:27:28 slave1 slapd[29274]: syncrepl_entry: be_modify (0)
And on the master you will see this:
> Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 PROXYAUTHZ dn="uid=user1,ou=people,dc=example,dc=com"
> Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD dn="uid=user1,ou=People,dc=example,dc=com"
> Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 MOD attr=mail
> Sep 6 09:23:57 ldapmaster slapd[2961]: conn=55902 op=3 RESULT tag=103 err=0 text=
Note: You can clearly see the PROXYAUTHZ line on the master, indicating the
proper identity assertion for the update on the master. Also note the slave
immediately receiving the Syncrepl update from the master.
> Sep 6 09:27:25 replica1 slapd[29274]: conn=11 fd=31 ACCEPT from IP=143.199.102.216:45181 (IP=143.199.102.216:389)
> Sep 6 09:27:25 replica1 slapd[29274]: conn=11 op=0 STARTTLS
> Sep 6 09:27:25 replica1 slapd[29274]: conn=11 op=0 RESULT oid= err=0 text=
> Sep 6 09:27:25 replica1 slapd[29274]: conn=11 fd=31 TLS established tls_ssf=256 ssf=256
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=people,dc=example,dc=com" method=128
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=1 BIND dn="uid=user1,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=1 RESULT tag=97 err=0 text=
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=2 MOD dn="uid=user1,ou=People,dc=example,dc=com"
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=2 MOD attr=mail
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=2 RESULT tag=103 err=0 text=
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 op=3 UNBIND
> Sep 6 09:27:28 replica1 slapd[29274]: conn=11 fd=31 closed
> Sep 6 09:27:28 replica1 slapd[29274]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
> Sep 6 09:27:28 replica1 slapd[29274]: syncrepl_entry: be_search (0)
> Sep 6 09:27:28 replica1 slapd[29274]: syncrepl_entry: uid=user1,ou=People,dc=example,dc=com
> Sep 6 09:27:28 replica1 slapd[29274]: syncrepl_entry: be_modify (0)
And on the provider you will see this:
> Sep 6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 PROXYAUTHZ dn="uid=user1,ou=people,dc=example,dc=com"
> Sep 6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 MOD dn="uid=user1,ou=People,dc=example,dc=com"
> Sep 6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 MOD attr=mail
> Sep 6 09:23:57 ldapprovider slapd[2961]: conn=55902 op=3 RESULT tag=103 err=0 text=
Note: You can clearly see the PROXYAUTHZ line on the provider, indicating the
proper identity assertion for the update on the provider. Also note the replica
immediately receiving the Syncrepl update from the provider.
H3: Handling Chaining Errors
......@@ -678,8 +678,8 @@ H2: The Proxy Cache Engine
{{TERM:LDAP}} servers typically hold one or more subtrees of a
{{TERM:DIT}}. Replica (or shadow) servers hold shadow copies of
entries held by one or more master servers. Changes are propagated
from the master server to replica (slave) servers using LDAP Sync
entries held by one or more provider servers. Changes are propagated
from the provider server to replica servers using LDAP Sync
replication. An LDAP cache is a special type of replica which holds
entries corresponding to search filters instead of subtrees.
......
This diff is collapsed.
......@@ -567,12 +567,12 @@ H4: olcSyncrepl
> [syncdata=default|accesslog|changelog]
This directive specifies the current database as a replica of the
master content by establishing the current {{slapd}}(8) as a
This directive specifies the current database as a consumer of the
provider content by establishing the current {{slapd}}(8) as a
replication consumer site running a syncrepl replication engine.
The master database is located at the replication provider site
specified by the {{EX:provider}} parameter. The replica database is
kept up-to-date with the master content using the LDAP Content
The provider database is located at the provider site
specified by the {{EX:provider}} parameter. The consumer database is
kept up-to-date with the provider content using the LDAP Content
Synchronization protocol. See {{REF:RFC4533}}
for more information on the protocol.
......@@ -583,19 +583,16 @@ described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
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}}
containing the provider content as an LDAP URI. The {{EX:provider}}
parameter specifies a scheme, a host and optionally a port where the
provider slapd instance can be found. Either a domain name or IP
address may be used for <hostname>. Examples are
{{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.
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 provider site. {{EX:syncrepl}} and
{{EX:replica}} directives define two independent replication
mechanisms. They do not represent the replication peers of each other.
specification is located on the consumer.
The content of the syncrepl replica is defined using a search
The content of the syncrepl consumer is defined using a search
specification as its result set. The consumer slapd will
send search requests to the provider slapd according to the search
specification. The search specification includes {{EX:searchbase}},
......@@ -618,7 +615,7 @@ synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default.
In the {{EX:refreshAndPersist}} operation, a synchronization search
remains persistent in the provider {{slapd}} instance. Further updates to the
master replica will generate {{EX:searchResultEntry}} to the consumer slapd
provider will generate {{EX:searchResultEntry}} to the consumer slapd
as the search responses to the persistent synchronization search.
If an error occurs during replication, the consumer will attempt to reconnect
......@@ -631,8 +628,8 @@ indefinite number of retries until success.
The schema checking can be enforced at the LDAP Sync consumer site
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
schema as the entry is stored on the consumer.
Every entry in the consumer 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.
......@@ -640,7 +637,7 @@ schema conformance. The default is off.
The {{EX:binddn}} parameter gives the DN to bind as for the
syncrepl searches to the provider slapd. It should be a DN
which has read access to the replication content in the
master database.
provider database.
The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
depending on whether simple password-based authentication or
......@@ -705,14 +702,15 @@ for more details.
H4: olcUpdateref: <URL>
This directive is only applicable in a slave slapd. It
This directive is only applicable in a {{replica}} (or {{shadow}})
{{slapd}}(8) instance. 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:
> olcUpdateref: ldap://master.example.net
> olcUpdateref: ldap://provider.example.net
H4: Sample Entries
......
......@@ -425,12 +425,12 @@ H4: syncrepl
> [syncdata=default|accesslog|changelog]
This directive specifies the current database as a replica of the
master content by establishing the current {{slapd}}(8) as a
This directive specifies the current database as a consumer of the
provider content by establishing the current {{slapd}}(8) as a
replication consumer site running a syncrepl replication engine.
The master database is located at the replication provider site
specified by the {{EX:provider}} parameter. The replica database is
kept up-to-date with the master content using the LDAP Content
The provider database is located at the replication provider site
specified by the {{EX:provider}} parameter. The consumer database is
kept up-to-date with the provider content using the LDAP Content
Synchronization protocol. See {{REF:RFC4533}}
for more information on the protocol.
......@@ -441,19 +441,16 @@ described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
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}}
containing the provider content as an LDAP URI. The {{EX:provider}}
parameter specifies a scheme, a host and optionally a port where the
provider slapd instance can be found. Either a domain name or IP
address may be used for <hostname>. Examples are
{{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.
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 provider site. {{EX:syncrepl}} and
{{EX:replica}} directives define two independent replication
mechanisms. They do not represent the replication peers of each other.
specification is located on the consumer.
The content of the syncrepl replica is defined using a search
The content of the syncrepl consumer is defined using a search
specification as its result set. The consumer slapd will
send search requests to the provider slapd according to the search
specification. The search specification includes {{EX:searchbase}},
......@@ -477,7 +474,7 @@ synchronization operation finishes. The interval is specified
by the {{EX:interval}} parameter. It is set to one day by default.
In the {{EX:refreshAndPersist}} operation, a synchronization search
remains persistent in the provider {{slapd}} instance. Further updates to the
master replica will generate {{EX:searchResultEntry}} to the consumer slapd
provider will generate {{EX:searchResultEntry}} to the consumer slapd
as the search responses to the persistent synchronization search.
If an error occurs during replication, the consumer will attempt to reconnect
......@@ -490,8 +487,8 @@ indefinite number of retries until success.
The schema checking can be enforced at the LDAP Sync consumer site
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
schema as the entry is stored on the consumer.
Every entry in the consumer 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.
......@@ -505,7 +502,7 @@ defaults for these parameters come from {{ldap.conf}}(5).
The {{EX:binddn}} parameter gives the DN to bind as for the
syncrepl searches to the provider slapd. It should be a DN
which has read access to the replication content in the
master database.
provider database.
The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
depending on whether simple password-based authentication or
......@@ -570,7 +567,7 @@ more information on how to use this directive.
H4: updateref <URL>
This directive is only applicable in a {{slave}} (or {{shadow}})
This directive is only applicable in a {{replica}} (or {{shadow}})
{{slapd}}(8) instance. It
specifies the URL to return to clients which submit update
requests upon the replica.
......@@ -578,7 +575,7 @@ If specified multiple times, each {{TERM:URL}} is provided.
\Example:
> updateref ldap://master.example.net
> updateref ldap://provider.example.net
H3: MDB Database Directives
......@@ -805,7 +802,7 @@ controls).
The next section of the configuration file defines a MDB
backend that will handle queries for things in the
"dc=example,dc=com" portion of the tree. The
database is to be replicated to two slave slapds, one on
database is to be replicated to two replica slapds, one on
truelies, the other on judgmentday. Indices are to be
maintained for several attributes, and the {{EX:userPassword}}
attribute is to be protected from unauthorized access.
......
......@@ -4621,7 +4621,7 @@
x="96.974648"
y="113.75929"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara27617">Master/Provider</flowPara></flowRoot> <flowRoot
id="flowPara27617">Provider</flowPara></flowRoot> <flowRoot
xml:space="preserve"
id="flowRoot3120"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial"
......
......@@ -5015,7 +5015,7 @@
x="137.38075"
y="681.46503"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara15542">Replica Pool</flowPara></flowRoot> <flowRoot
id="flowPara15542">Consumer Pool</flowPara></flowRoot> <flowRoot
xml:space="preserve"
id="flowRoot15534"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial"
......@@ -5027,7 +5027,7 @@
x="137.38075"
y="681.46503"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara15544">Replica Pool</flowPara></flowRoot> <path
id="flowPara15544">Consumer Pool</flowPara></flowRoot> <path
style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.71494228px;stroke-linecap:butt;stroke-linejoin:miter;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend);stroke-opacity:1"
d="M 254.55844,186.23712 L 254.55844,261.49474"
id="path16515" />
......
......@@ -13,12 +13,12 @@
id="svg7893"
inkscape:version="0.46"
sodipodi:docbase="/home/ghenry/Desktop"
sodipodi:docname="n-way-multi-master.svg"
sodipodi:docname="n-way-multi-provider.svg"
sodipodi:version="0.32"
width="744.09448"
inkscape:output_extension="org.inkscape.output.svg.inkscape"
version="1.0"
inkscape:export-filename="/home/ghenry/Desktop/n-way-multi-master.png"
inkscape:export-filename="/home/ghenry/Desktop/n-way-multi-provider.png"
inkscape:export-xdpi="90"
inkscape:export-ydpi="90">
<metadata
......@@ -4573,7 +4573,7 @@
x="194.28572"
y="475.52304"
style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara6968">N-Way Multi-Master</flowPara></flowRoot> <text
id="flowPara6968">N-Way Multi-Provider</flowPara></flowRoot> <text
xml:space="preserve"
style="font-size:40px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
x="316"
......
......@@ -4667,7 +4667,7 @@
x="96.974648"
y="113.75929"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara27617">Master/Provider</flowPara></flowRoot> <g
id="flowPara27617">Provider</flowPara></flowRoot> <g
id="g3073"
transform="matrix(0.1267968,0,0,0.1710106,264.00249,370.01498)">
<path
......@@ -4739,7 +4739,7 @@
x="412.14224"
y="279.42432"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara3136">Primary directory also contains back-ldap databases that replicate from the Master directory and push out changes to the replicas</flowPara></flowRoot> <flowRoot
id="flowPara3136">Primary directory also contains back-ldap databases that replicate from the provider directory and push out changes to the replicas</flowPara></flowRoot> <flowRoot
xml:space="preserve"
id="flowRoot6975"
style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
......
......@@ -4691,7 +4691,7 @@
x="96.974648"
y="113.75929"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara27617">Master/Provider</flowPara></flowRoot> <g
id="flowPara27617">Provider</flowPara></flowRoot> <g
id="g3073"
transform="matrix(0.1267968,0,0,0.1710106,264.00249,370.01498)"
inkscape:export-filename="/anything/src/openldap/ldap/doc/guide/images/src/push-based-complete.png"
......@@ -4772,7 +4772,7 @@
x="412.14224"
y="279.42432"
style="font-size:18px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Arial" /></flowRegion><flowPara
id="flowPara3136">Primary directory is a standard OpenLDAP Master, ldap proxy using Syncrepl pulls in changes from the master and pushes out to replicas. Useful if you don't have access to original master.</flowPara></flowRoot> <flowRoot
id="flowPara3136">Primary directory is a standard OpenLDAP provider, ldap proxy using Syncrepl pulls in changes from the provider and pushes out to replicas. Useful if you don't have access to original provider.</flowPara></flowRoot> <flowRoot
xml:space="preserve"
id="flowRoot6975"
style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
......
......@@ -235,7 +235,7 @@ the attribute type is non-operational.
.TP
.B LDAP_SCHEMA_DIRECTORY_OPERATION
the attribute type is operational and is pertinent to the directory
itself, i.e. it has the same value on all servers that master the
itself, i.e. it has the same value on all servers that provide the
entry containing this attribute type.
.TP
.B LDAP_SCHEMA_DISTRIBUTED_OPERATION
......@@ -245,7 +245,7 @@ shadowing or other distributed directory aspect. TBC.
.B LDAP_SCHEMA_DSA_OPERATION
the attribute type is operational and is pertinent to the directory
server itself, i.e. it may have different values for the same entry
when retrieved from different servers that master the entry.
when retrieved from different servers that provide the entry.
.LP
Object classes can be of three kinds:
.TP
......
......@@ -711,7 +711,7 @@ environment. The attribute "cmusaslsecretOTP" is the default value.
.B olcSaslAuxpropsDontUseCopyIgnore TRUE | FALSE
Used to disable replication of the attribute(s) defined by
olcSaslAuxpropsDontUseCopy and instead use a local value for the attribute. This
allows the SASL mechanism to continue to work if the master is offline. This can
allows the SASL mechanism to continue to work if the provider is offline. This can
cause replication inconsistency. Defaults to FALSE.
.TP
.B olcSaslHost: <fqdn>
......@@ -773,15 +773,15 @@ Specify an integer ID from 0 to 4095 for this server (limited
to 3 hexadecimal digits). The ID may also be specified as a
hexadecimal ID by prefixing the value with "0x".
Non-zero IDs are
required when using multimaster replication and each master must have a
unique non-zero ID. Note that this requirement also applies to separate masters
required when using multi-provider replication and each provider must have a
unique non-zero ID. Note that this requirement also applies to separate providers
contributing to a glued set of databases.
If the URL is provided, this directive may be specified
multiple times, providing a complete list of participating servers
and their IDs. The fully qualified hostname of each server should be
used in the supplied URLs. The IDs are used in the "replica id" field
of all CSNs generated by the specified server. The default value is zero, which
is only valid for single master replication.
is only valid for single provider replication.
Example:
.LP
.nf
......@@ -1624,7 +1624,7 @@ Specifies the maximum number of aliases to dereference when trying to
resolve an entry, used to avoid infinite alias loops. The default is 15.
.TP
.B olcMirrorMode: TRUE | FALSE
This option puts a replica database into "mirror" mode. Update
This option puts a consumer database into "mirror" mode. Update
operations will be accepted from any user, not just the updatedn. The
database must already be configured as syncrepl consumer
before this keyword may be set. This mode also requires a
......@@ -1780,13 +1780,13 @@ FALSE, meaning the contextCSN is stored in the context entry.
.B [syncdata=default|accesslog|changelog]
.B [lazycommit]
.RS
Specify the current database as a replica which is kept up-to-date with the
master content by establishing the current
Specify the current database as a consumer which is kept up-to-date with the
provider content by establishing the current
.BR slapd (8)
as a replication consumer site running a
.B syncrepl
replication engine.
The replica content is kept synchronized to the master content using
The consumer content is kept synchronized to the provider content using
the LDAP Content Synchronization protocol. Refer to the
"OpenLDAP Administrator's Guide" for detailed information on
setting up a replicated
......@@ -1802,13 +1802,13 @@ directive within the replication consumer site.
It is a non-negative integer having no more than three decimal digits.
.B provider
specifies the replication provider site containing the master content
specifies the replication provider site containing the provider content
as an LDAP URI. If <port> is not given, the standard LDAP port number
(389 or 636) is used.
The content of the
.B syncrepl
replica is defined using a search
consumer is defined using a search
specification as its result set. The consumer
.B slapd
will send search requests to the provider
......@@ -1843,7 +1843,7 @@ after each synchronization operation finishes.
In the
.B refreshAndPersist
operation, a synchronization search remains persistent in the provider slapd.
Further updates to the master replica will generate
Further updates to the provider will generate
.B searchResultEntry
to the consumer slapd as the search responses to the persistent
synchronization search. If the initial search fails due to an error, the
......@@ -1972,7 +1972,7 @@ for the consumer, while sacrificing safety or durability.
.RE
.TP
.B olcUpdateDN: <dn>
This option is only applicable in a slave
This option is only applicable in a replica
database.
It specifies the DN permitted to update (subject to access controls)
the replica. It is only needed in certain push-mode
......@@ -1980,7 +1980,7 @@ replication scenarios. Generally, this DN
.I should not
be the same as the
.B rootdn
used at the master.
used at the provider.
.TP
.B olcUpdateRef: <url>
Specify the referral to pass back when
......
......@@ -861,7 +861,7 @@ environment. The attribute "cmusaslsecretOTP" is the default value.
.B sasl\-auxprops\-dontusecopy\-ignore on | off
Used to disable replication of the attribute(s) defined by
sasl-auxprops-dontusecopy and instead use a local value for the attribute. This
allows the SASL mechanism to continue to work if the master is offline. This can
allows the SASL mechanism to continue to work if the provider is offline. This can
cause replication inconsistency. Defaults to off.
.TP
.B sasl\-host <fqdn>
......@@ -962,15 +962,15 @@ Specify an integer ID from 0 to 4095 for this server (limited
to 3 hexadecimal digits). The ID may also be specified as a
hexadecimal ID by prefixing the value with "0x".
Non-zero IDs are
required when using multimaster replication and each master must have a
unique non-zero ID. Note that this requirement also applies to separate masters
required when using multi-provider replication and each provider must have a
unique non-zero ID. Note that this requirement also applies to separate providers
contributing to a glued set of databases.
If the URL is provided, this directive may be specified
multiple times, providing a complete list of participating servers
and their IDs. The fully qualified hostname of each server should be
used in the supplied URLs. The IDs are used in the "replica id" field