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

contrib/ldaptcl/ldap.n

@@ -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:
 

contrib/slapd-modules/lastbind/slapo-lastbind.5

@@ -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

doc/guide/admin/Makefile

@@ -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 \

doc/guide/admin/config.sdf

@@ -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"

doc/guide/admin/intro.sdf

@@ -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.
 

doc/guide/admin/maintenance.sdf

@@ -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.
 

doc/guide/admin/overlays.sdf

@@ -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.
 

doc/guide/admin/slapdconf2.sdf

@@ -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

doc/guide/admin/slapdconfig.sdf

@@ -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.

doc/guide/images/src/delta-syncrepl.svg

@@ -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"

doc/guide/images/src/dual_dc.svg

@@ -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" />

doc/guide/images/src/n-way-multi-master.svg → doc/guide/images/src/n-way-multi-provider.svg

@@ -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"

doc/guide/images/src/push-based-complete.svg

@@ -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"

doc/guide/images/src/push-based-standalone.svg

@@ -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"

doc/man/man3/ldap_schema.3

@@ -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

doc/man/man5/slapd-config.5

@@ -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

doc/man/man5/slapd.conf.5

@@ -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
 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
@@ -1567,7 +1567,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 mirrormode on | off
-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 a syncrepl consumer
 before this keyword may be set. This mode also requires a
@@ -1759,13 +1759,13 @@ 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