More syncrepl cleanup

doc/guide/admin/slapdconfig.sdf

@@ -430,7 +430,6 @@ H4: syncrepl
 >		[sizelimit=<limit>]
 >		[timelimit=<limit>]
 >		[schemachecking=on|off]
->		[updatedn=<DN>]
 >		[bindmethod=simple|sasl]
 >		[binddn=<DN>]
 >		[saslmech=<mech>]
@@ -507,15 +506,6 @@ 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}} 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.  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
 which has read access to the replication content in the
@@ -597,33 +587,6 @@ containing the database and associated indices live.
 >	directory /usr/local/var/openldap-data
 
 
-H4: sessionlog <sid> <limit>
-
-This directive specifies a session log store in the syncrepl 
-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 decimal digits.
-
-The LDAP Content Synchronization operation that falls into a pre-existing
-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
-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
 
 Directives in this category only apply to a {{TERM:LDBM}} database.

doc/guide/admin/syncrepl.sdf

@@ -232,30 +232,25 @@ yielded a greater {{EX:entryCSN}} than was previously recorded in the
 suffix entry's {{EX:contextCSN}} attribute, a checkpoint will be immediately
 written with the new value.
 
-The consumer stores its replica state, which is the provider's
+The consumer also stores its replica state, which is the provider's
 {{EX:contextCSN}} received as a synchronization cookie,
-in the {{EX:syncreplCookie}} attribute of the immediate child
-of the context suffix whose DN is {{cn=syncrepl<rid>,<suffix>}}
-and object class is {{EX:syncConsumerSubentry}}.
+in the {{EX:contextCSN}} attribute of the suffix entry.
 The replica state maintained by a consumer server is used as the
 synchronization state indicator when it performs subsequent incremental
 synchronization with the provider server. It is also used as a
 provider-side synchronization state indicator when it functions as
 a secondary provider server in a cascading replication configuration.
-<rid> is the replica ID uniquely identifying the replica locally in the
-syncrepl consumer server. <rid> is an integer which has no more than
-three decimal digits.
-
-It is possible to retrieve the
-{{EX:syncConsumerSubentry}} by performing an LDAP search with
-the respective entry as the base object and with the base scope.
+Since the consumer and provider state information are maintained in
+the same location within their respective databases, any consumer
+can be promoted to a provider (and vice versa) without any special
+actions.
 
 Because a general search filter can be used in the syncrepl specification,
 some entries in the context may be omitted from the synchronization content.
 The syncrepl engine creates a glue entry to fill in the holes
 in the replica context if any part of the replica content is
 subordinate to the holes. The glue entries will not be returned
-as the search result unless {{ManageDsaIT}} control is provided.
+in the search result unless {{ManageDsaIT}} control is provided.
 
 Also as a consequence of the search filter used in the syncrepl
 specification, it is possible for a modification to remove an
@@ -271,9 +266,8 @@ specification is defined in {{slapd.conf}} (5) of the consumer server,
 not in the provider server's configuration file.
 The initial loading of the replica content can be performed either
 by starting the syncrepl engine with no synchronization cookie
-or by populating the consumer replica by adding and demoting an
+or by populating the consumer replica by adding an
 {{TERM:LDIF}} file dumped as a backup at the provider.
-{{slapadd}} (8) supports the replica promotion and demotion.
 
 When loading from a backup, it is not required to perform the initial
 loading from the up-to-date backup of the provider content. The syncrepl
@@ -307,15 +301,12 @@ since the last checkpoint, a new checkpoint is performed.
 
 The session log is configured by the
 
->	syncprov-sessionlog <sid> <size>
+>	syncprov-sessionlog <size>
 
-directive, where {{<sid>}} is the ID of the per-scope session log
-in the provider server and {{<size>}} is the maximum number of
-session log entries the session log can record. {{<sid>}}
-is an integer no longer than 3 decimal digits. If the consumer
-server sends a synchronization cookie containing {{sid=<sid>}}
-where {{<sid>}} matches the session log ID specified in the directive,
-the LDAP Sync search is to utilize the session log.
+directive, where {{<size>}} is the maximum number of
+session log entries the session log can record. When a session log
+is configured, it is automatically used for all LDAP Sync searches
+within the database.
 
 Note that using the session log requires searching on the {{entryUUID}}
 attribute. Setting an eq index on this attribute will greatly
@@ -331,7 +322,7 @@ A more complete example of the {{slapd.conf}} content is thus:
 >
 >	overlay syncprov
 >	syncprov-checkpoint 100 10
->	syncprov-sessionlog 0 100
+>	syncprov-sessionlog 100
 
 
 H3: Set up the consumer slapd
@@ -366,7 +357,9 @@ polling ({{refreshOnly}}) mode of synchronization once a day.  It will
 bind as {{EX:cn=syncuser,dc=example,dc=com}} using simple authentication
 with password "secret".  Note that the access control privilege of
 {{EX:cn=syncuser,dc=example,dc=com}} should be set appropriately 
-in the provider to retrieve the desired replication content.
+in the provider to retrieve the desired replication content. Also
+the search limits must be high enough on the provider to allow the
+syncuser to retrieve a complete copy of the requested content.
 The consumer uses the rootdn to write to its database so it
 always has full permissions to write all content.
 
@@ -386,21 +379,20 @@ H3: Start the provider and the consumer slapd
 
 The provider {{slapd}} (8) is not required to be restarted.
 {{contextCSN}} is automatically generated as needed:
-it might originally contained in the {{TERM:LDIF}} file,
+it might be originally contained in the {{TERM:LDIF}} file,
 generated by {{slapadd}} (8), generated upon changes in the context,
-or generated when the first LDAP Sync search arrived at the provider.
+or generated when the first LDAP Sync search arrives at the provider.
 
 When starting a consumer {{slapd}} (8), it is possible to provide a
 synchronization cookie as the {{-c cookie}} command line option
 in order to start the synchronization from a specific state.
 The cookie is a comma separated list of name=value pairs. Currently
-supported syncrepl cookie fields are {{csn=<csn>}}, {{sid=<sid>}}, and
+supported syncrepl cookie fields are {{csn=<csn>}} and
 {{rid=<rid>}}. {{<csn>}} represents the current synchronization state
-of the consumer replica. {{<sid>}} is the identity of the per-scope
-session log to which this consumer will be associated. {{<rid>}} identifies
+of the consumer replica.  {{<rid>}} identifies
 a consumer replica locally within the consumer server. It is used to relate
 the cookie to the syncrepl definition in {{slapd.conf}} (5) which has
 the matching replica identifier.
-Both {{<sid>}} and {{<rid>}} have no more than 3 decimal digits.
+The {{<rid>}} must have no more than 3 decimal digits.
 The command line cookie overrides the synchronization cookie
 stored in the consumer replica database.