8
8
resilient enterprise deployment.
10
10
{{PRD:OpenLDAP}} has various configuration options for creating a replicated
11
directory. The following sections will discuss these.
18
{{Slurpd}} replication has been deprecated in favor of Syncrepl replication and
19
has been completely removed from OpenLDAP 2.4.
21
{{Why was it replaced?}}
23
The {{slurpd}} daemon was the original replication mechanism inherited from
24
UMich's LDAP and operates in push mode: the master pushes changes to the
25
slaves. It has been replaced for many reasons, in brief:
28
* It is extremely sensitive to the ordering of records in the replog
29
* It can easily go out of sync, at which point manual intervention is
30
required to resync the slave database with the master directory
31
* It isn't very tolerant of unavailable servers. If a slave goes down
32
for a long time, the replog may grow to a size that's too large for
35
{{What was it replaced with?}}
39
{{Why is Syncrepl better?}}
41
* Syncrepl is self-synchronizing; you can start with a database in any
42
state from totally empty to fully synced and it will automatically do
43
the right thing to achieve and maintain synchronization
44
* Syncrepl can operate in either direction
45
* Data updates can be minimal or maximal
47
{{How do I implement a pushed based replication system using Syncrepl?}}
49
The easiest way is to point an LDAP backend ({{SECT: Backends}} and {{slapd-ldap(8)}})
50
to your slave directory and setup Syncrepl to point to your Master database.
52
If you imagine Syncrepl pulling down changes from the Master server, and then
53
pushing those changes out to your slave servers via {{slapd-ldap(8)}}. This is
54
called Syncrepl Proxy Mode. You can also use Syncrepl Multi-proxy mode:
56
!import "push-based-complete.png"; align="center"; title="Syncrepl Proxy Mode"
57
FT[align="Center"] Figure X.Y: Replacing slurpd
59
The following example is for a self-contained push-based replication solution:
61
> #######################################################################
62
> # Standard OpenLDAP Master/Provider
63
> #######################################################################
65
> include /usr/local/etc/openldap/schema/core.schema
66
> include /usr/local/etc/openldap/schema/cosine.schema
67
> include /usr/local/etc/openldap/schema/nis.schema
68
> include /usr/local/etc/openldap/schema/inetorgperson.schema
70
> include /usr/local/etc/openldap/slapd.acl
72
> modulepath /usr/local/libexec/openldap
73
> moduleload back_hdb.la
74
> moduleload syncprov.la
75
> moduleload back_monitor.la
76
> moduleload back_ldap.la
78
> pidfile /usr/local/var/slapd.pid
79
> argsfile /usr/local/var/slapd.args
84
> suffix "dc=suretecsystems,dc=com"
85
> directory /usr/local/var/openldap-data
91
> index objectClass eq
95
> rootdn "cn=admin,dc=suretecsystems,dc=com"
98
> # syncprov specific indexing
102
> # syncrepl Provider for primary db
104
> syncprov-checkpoint 1000 60
106
> # Let the replica DN have limitless searches
107
> limits dn.exact="cn=replicator,dc=suretecsystems,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
114
> ##############################################################################
115
> # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
116
> ##############################################################################
119
> # ignore conflicts with other databases, as we need to push out to same suffix
121
> suffix "dc=suretecsystems,dc=com"
122
> rootdn "cn=slapd-ldap"
123
> uri ldap://localhost:9012/
127
> # We don't need any access to this DSA
130
> acl-bind bindmethod=simple
131
> binddn="cn=replicator,dc=suretecsystems,dc=com"
132
> credentials=testing
135
> provider=ldap://localhost:9011/
136
> binddn="cn=replicator,dc=suretecsystems,dc=com"
138
> credentials=testing
139
> searchbase="dc=suretecsystems,dc=com"
140
> type=refreshAndPersist
145
A replica configuration for this type of setup could be:
147
> #######################################################################
148
> # Standard OpenLDAP Slave without Syncrepl
149
> #######################################################################
151
> include /usr/local/etc/openldap/schema/core.schema
152
> include /usr/local/etc/openldap/schema/cosine.schema
153
> include /usr/local/etc/openldap/schema/nis.schema
154
> include /usr/local/etc/openldap/schema/inetorgperson.schema
156
> include /usr/local/etc/openldap/slapd.acl
158
> modulepath /usr/local/libexec/openldap
159
> moduleload back_hdb.la
160
> moduleload syncprov.la
161
> moduleload back_monitor.la
162
> moduleload back_ldap.la
164
> pidfile /usr/local/var/slapd.pid
165
> argsfile /usr/local/var/slapd.args
167
> loglevel sync stats
170
> suffix "dc=suretecsystems,dc=com"
171
> directory /usr/local/var/openldap-slave/data
177
> index objectClass eq
181
> rootdn "cn=admin,dc=suretecsystems,dc=com"
184
> # Let the replica DN have limitless searches
185
> limits dn.exact="cn=replicator,dc=suretecsystems,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
187
> updatedn "cn=replicator,dc=suretecsystems,dc=com"
189
> # Refer updates to the master
190
> updateref ldap://localhost:9011
197
You can see we use the {{updatedn}} directive here and example ACLs ({{F:usr/local/etc/openldap/slapd.acl}}) for this could be:
199
> # Give the replica DN unlimited read access. This ACL may need to be
200
> # merged with other ACL statements.
203
> by dn.base="cn=replicator,dc=suretecsystems,dc=com" write
206
> access to dn.base=""
209
> access to dn.base="cn=Subschema"
212
> access to dn.subtree="cn=Monitor"
213
> by dn.exact="uid=admin,dc=suretecsystems,dc=com" write
221
In order to support more replicas, just add more {{database ldap}} sections and
222
increment the {{syncrepl rid}} number accordingly.
224
Note: You must populate the Master and Slave directories with the same data,
225
unlike when using normal Syncrepl
227
If you do not have access to modify the master directory configuration you can
228
configure a standalone ldap proxy, which might look like:
230
!import "push-based-standalone.png"; align="center"; title="Syncrepl Standalone Proxy Mode"
231
FT[align="Center"] Figure X.Y: Replacing slurpd with a standalone version
233
The following configuration is an example of a standalone LDAP Proxy:
235
> include /usr/local/etc/openldap/schema/core.schema
236
> include /usr/local/etc/openldap/schema/cosine.schema
237
> include /usr/local/etc/openldap/schema/nis.schema
238
> include /usr/local/etc/openldap/schema/inetorgperson.schema
240
> include /usr/local/etc/openldap/slapd.acl
242
> modulepath /usr/local/libexec/openldap
243
> moduleload syncprov.la
244
> moduleload back_ldap.la
246
> ##############################################################################
247
> # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
248
> ##############################################################################
251
> # ignore conflicts with other databases, as we need to push out to same suffix
253
> suffix "dc=suretecsystems,dc=com"
254
> rootdn "cn=slapd-ldap"
255
> uri ldap://localhost:9012/
259
> # We don't need any access to this DSA
262
> acl-bind bindmethod=simple
263
> binddn="cn=replicator,dc=suretecsystems,dc=com"
264
> credentials=testing
267
> provider=ldap://localhost:9011/
268
> binddn="cn=replicator,dc=suretecsystems,dc=com"
270
> credentials=testing
271
> searchbase="dc=suretecsystems,dc=com"
272
> type=refreshAndPersist
277
As you can see, you can let your imagination go wild using Syncrepl and
278
{{slapd-ldap(8)}} tailoring your replication to fit your specific network
11
directory. In previous releases, replication was discussed in terms of
12
a {{master}} server and some number of {{slave}} servers. A master
13
accepted directory updates from other clients, and a slave only
14
accepted updates from a (single) master. The replication structure
15
was rigidly defined and any particular database could only fulfill
16
a single role, either master or slave.
18
As OpenLDAP now supports a wide variety of replication topologies, these
19
terms have been deprecated in favor of {{provider}} and
20
{{consumer}}: A provider replicates directory updates to consumers;
21
consumers receive replication updates from providers. Unlike the
22
rigidly defined master/slave relationships, provider/consumer roles
23
are quite fluid: replication updates received in a consumer can be
24
further propagated by that consumer to other servers, so a consumer
25
can also act simultaneously as a provider. Also, a consumer need not
26
be an actual LDAP server; it may be just an LDAP client.
28
The following sections will describe the replication technology and
29
discuss the various replication options that are available.
31
H2: Replication Technology
283
33
H3: LDAP Sync Replication
285
35
The {{TERM:LDAP Sync}} Replication engine, {{TERM:syncrepl}} for
286
36
short, is a consumer-side replication engine that enables the
287
37
consumer {{TERM:LDAP}} server to maintain a shadow copy of a
288
{{TERM:DIT}} fragment. A syncrepl engine resides at the consumer-side
289
as one of the {{slapd}}(8) threads. It creates and maintains a
38
{{TERM:DIT}} fragment. A syncrepl engine resides at the consumer
39
and executes as one of the {{slapd}}(8) threads. It creates and maintains a
290
40
consumer replica by connecting to the replication provider to perform
291
41
the initial DIT content load followed either by periodic content
292
42
polling or by timely updates upon content changes.
294
Syncrepl uses the LDAP Content Synchronization (or LDAP Sync for
295
short) protocol as the replica synchronization protocol. It provides
44
Syncrepl uses the LDAP Content Synchronization protocol (or LDAP Sync for
45
short) as the replica synchronization protocol. LDAP Sync provides
296
46
a stateful replication which supports both pull-based and push-based
297
47
synchronization and does not mandate the use of a history store.
48
In pull-based replication the consumer periodically
49
polls the provider for updates. In push-based replication the consumer
50
listens for updates that are sent by the provider in realtime. Since the
51
protocol does not require a history store, the provider does not need to
52
maintain any log of updates it has received. (Note
53
that the syncrepl engine is extensible and additional replication
54
protocols may be supported in the future.)
299
56
Syncrepl keeps track of the status of the replication content by
300
57
maintaining and exchanging synchronization cookies. Because the
346
103
operation. This section introduces the LDAP Content Sync protocol
347
104
only briefly. For more information, refer to {{REF:RFC4533}}.
349
The LDAP Sync protocol supports both polling and listening for
350
changes by defining two respective synchronization operations:
106
The LDAP Sync protocol supports both polling and listening for changes
107
by defining two respective synchronization operations:
351
108
{{refreshOnly}} and {{refreshAndPersist}}. Polling is implemented
352
by the {{refreshOnly}} operation. The client copy is synchronized
353
to the server copy at the time of polling. The server finishes the
109
by the {{refreshOnly}} operation. The consumer
110
polls the provider using an LDAP Search request with an LDAP Sync
111
control attached. The consumer copy is synchronized
112
to the provider copy at the time of polling using the information
113
returned in the search. The provider finishes the
354
114
search operation by returning {{SearchResultDone}} at the end of
355
the search operation as in the normal search. The listening is
356
implemented by the {{refreshAndPersist}} operation. Instead of
115
the search operation as in the normal search. Listening is
116
implemented by the {{refreshAndPersist}} operation. As the name
117
implies, it begins with a search, like refreshOnly. Instead of
357
118
finishing the search after returning all entries currently matching
358
119
the search criteria, the synchronization search remains persistent
359
in the server. Subsequent updates to the synchronization content
360
in the server cause additional entry updates to be sent to the
120
in the provider. Subsequent updates to the synchronization content
121
in the provider cause additional entry updates to be sent to the
363
124
The {{refreshOnly}} operation and the refresh stage of the
364
125
{{refreshAndPersist}} operation can be performed with a present
365
126
phase or a delete phase.
367
In the present phase, the server sends the client the entries updated
368
within the search scope since the last synchronization. The server
369
sends all requested attributes, be it changed or not, of the updated
128
In the present phase, the provider sends the consumer the entries updated
129
within the search scope since the last synchronization. The provider
130
sends all requested attributes, be they changed or not, of the updated
370
131
entries. For each unchanged entry which remains in the scope, the
371
server sends a present message consisting only of the name of the
132
provider sends a present message consisting only of the name of the
372
133
entry and the synchronization control representing state present.
373
134
The present message does not contain any attributes of the entry.
374
After the client receives all update and present entries, it can
375
reliably determine the new client copy by adding the entries added
376
to the server, by replacing the entries modified at the server, and
377
by deleting entries in the client copy which have not been updated
378
nor specified as being present at the server.
135
After the consumer receives all update and present entries, it can
136
reliably determine the new consumer copy by adding the entries added
137
to the provider, by replacing the entries modified at the provider, and
138
by deleting entries in the consumer copy which have not been updated
139
nor specified as being present at the provider.
380
141
The transmission of the updated entries in the delete phase is the
381
same as in the present phase. The server sends all the requested
142
same as in the present phase. The provider sends all the requested
382
143
attributes of the entries updated within the search scope since the
383
last synchronization to the client. In the delete phase, however,
384
the server sends a delete message for each entry deleted from the
144
last synchronization to the consumer. In the delete phase, however,
145
the provider sends a delete message for each entry deleted from the
385
146
search scope, instead of sending present messages. The delete
386
147
message consists only of the name of the entry and the synchronization
387
control representing state delete. The new client copy can be
148
control representing state delete. The new consumer copy can be
388
149
determined by adding, modifying, and removing entries according to
389
150
the synchronization control attached to the {{SearchResultEntry}}
392
In the case that the LDAP Sync server maintains a history store and
393
can determine which entries are scoped out of the client copy since
394
the last synchronization time, the server can use the delete phase.
395
If the server does not maintain any history store, cannot determine
153
In the case that the LDAP Sync provider maintains a history store and
154
can determine which entries are scoped out of the consumer copy since
155
the last synchronization time, the provider can use the delete phase.
156
If the provider does not maintain any history store, cannot determine
396
157
the scoped-out entries from the history store, or the history store
397
does not cover the outdated synchronization state of the client,
398
the server should use the present phase. The use of the present
158
does not cover the outdated synchronization state of the consumer,
159
the provider should use the present phase. The use of the present
399
160
phase is much more efficient than a full content reload in terms
400
161
of the synchronization traffic. To reduce the synchronization
401
162
traffic further, the LDAP Sync protocol also provides several
538
296
For configuration, please see the {{SECT:Syncrepl}} section.
299
H2: Deployment Alternatives
301
While the LDAP Sync specification only defines a narrow scope for replication,
302
the OpenLDAP implementation is extremely flexible and supports a variety of
303
operating modes to handle other scenarios not explicitly addressed in the spec.
541
306
H3: Delta-syncrepl replication
543
* Disadvantages of Syncrepl replication:
308
* Disadvantages of LDAP Sync replication:
545
OpenLDAP's syncrepl replication is an object-based replication mechanism.
310
LDAP Sync replication is an object-based replication mechanism.
546
311
When any attribute value in a replicated object is changed on the provider,
547
each consumer fetches and processes the complete changed object {B:both changed and unchanged attribute values}
548
during replication. This works well, but has drawbacks in some situations.
312
each consumer fetches and processes the complete changed object, including
313
{{B:both the changed and unchanged attribute values}} during replication.
314
One advantage of this approach is that when multiple changes occur to
315
a single object, the precise sequence of those changes need not be preserved;
316
only the final state of the entry is significant. But this approach
317
may have drawbacks when the usage pattern involves single changes to
550
320
For example, suppose you have a database consisting of 100,000 objects of 1 KB
551
321
each. Further, suppose you routinely run a batch job to change the value of
552
322
a single two-byte attribute value that appears in each of the 100,000 objects
553
323
on the master. Not counting LDAP and TCP/IP protocol overhead, each time you
554
run this job each consumer will transfer and process {B:1 GB} of data to process
555
{B:200KB of changes! }
324
run this job each consumer will transfer and process {{B:1 GB}} of data to
325
process {{B:200KB of changes!}}
557
327
99.98% of the data that is transmitted and processed in a case like this will
558
328
be redundant, since it represents values that did not change. This is a waste
566
336
Delta-syncrepl, a changelog-based variant of syncrepl, is designed to address
567
337
situations like the one described above. Delta-syncrepl works by maintaining a
568
changelog of a selectable depth on the provider. The replication consumer on
569
each consumer checks the changelog for the changes it needs and, as long as
570
the changelog contains the needed changes, the delta-syncrepl consumer fetches
571
them from the changelog and applies them to its database. If, however, a replica
338
changelog of a selectable depth on the provider. The replication consumer
339
checks the changelog for the changes it needs and, as long as
340
the changelog contains the needed changes, the consumer fetches the changes
341
from the changelog and applies them to its database. If, however, a replica
572
342
is too far out of sync (or completely empty), conventional syncrepl is used to
573
bring it up to date and replication then switches to the delta-syncrepl mode.
343
bring it up to date and replication then switches back to the delta-syncrepl
575
346
For configuration, please see the {{SECT:Delta-syncrepl}} section.
578
H2: Mixture of both Pull and Push based
580
349
H3: N-Way Multi-Master replication
582
351
Multi-Master replication is a replication technique using Syncrepl to replicate
583
data to multiple Master Directory servers.
585
* Advantages of Multi-Master replication:
587
- If any master fails, other masters will continue to accept updates
588
- Avoids a single point of failure
589
- Masters can be located in several physical sites i.e. distributed across the
591
- Good for Automatic failover/High Availability
593
* Disadvantages of Multi-Master replication:
595
- It has {{B:NOTHING}} to do with load balancing
596
- {{URL:http://www.openldap.org/faq/data/cache/1240.html}}
597
- If connectivity with a master is lost because of a network partition, then
352
data to multiple provider ("Master") Directory servers.
354
H4: Valid Arguments for Multi-Master replication
356
* If any provider fails, other providers will continue to accept updates
357
* Avoids a single point of failure
358
* Providers can be located in several physical sites i.e. distributed across
360
* Good for Automatic failover/High Availability
362
H4: Invalid Arguments for Multi-Master replication
364
(These are often claimed to be advantages of Multi-Master replication but
365
those claims are false):
367
* It has {{B:NOTHING}} to do with load balancing
368
* Providers {{B:must}} propagate writes to {{B:all}} the other servers, which
369
means the network traffic and write load spreads across all
370
of the servers the same as for single-master.
371
* Server utilization and performance are at best identical for
372
Multi-Master and Single-Master replication; at worst Single-Master is
373
superior because indexing can be tuned differently to optimize for the
374
different usage patterns between the provider and the consumers.
376
H4: Arguments against Multi-Master replication
378
* Breaks the data consistency guarantees of the directory model
379
* {{URL:http://www.openldap.org/faq/data/cache/1240.html}}
380
* If connectivity with a provider is lost because of a network partition, then
598
381
"automatic failover" can just compound the problem
599
- Typically, a particular machine cannot distinguish between losing contact
382
* Typically, a particular machine cannot distinguish between losing contact
600
383
with a peer because that peer crashed, or because the network link has failed
601
- If a network is partitioned and multiple clients start writing to each of the
384
* If a network is partitioned and multiple clients start writing to each of the
602
385
"masters" then reconciliation will be a pain; it may be best to simply deny
603
writes to the clients that are partitioned from the single master
604
- Masters {{B:must}} propagate writes to {{B:all}} the other servers, which
605
means the network traffic and write load is constant and spreads across all
386
writes to the clients that are partitioned from the single provider
609
389
For configuration, please see the {{SECT:N-Way Multi-Master}} section below
613
393
MirrorMode is a hybrid configuration that provides all of the consistency
614
394
guarantees of single-master replication, while also providing the high
615
availability of multi-master. In MirrorMode two masters are set up to
616
replicate from each other (as a multi-master configuration) but an
395
availability of multi-master. In MirrorMode two providers are set up to
396
replicate from each other (as a multi-master configuration), but an
617
397
external frontend is employed to direct all writes to only one of
618
the two servers. The second master will only be used for writes if
619
the first master crashes, at which point the frontend will switch to
620
directing all writes to the second master. When a crashed master is
398
the two servers. The second provider will only be used for writes if
399
the first provider crashes, at which point the frontend will switch to
400
directing all writes to the second provider. When a crashed provider is
621
401
repaired and restarted it will automatically catch up to any changes
622
on the running master and resync.
402
on the running provider and resync.
624
404
H4: Arguments for MirrorMode
626
406
* Provides a high-availability (HA) solution for directory writes (replicas handle reads)
627
* As long as one Master is operational, writes can safely be accepted
628
* Master nodes replicate from each other, so they are always up to date and
407
* As long as one provider is operational, writes can safely be accepted
408
* Provider nodes replicate from each other, so they are always up to date and
629
409
can be ready to take over (hot standby)
630
* Syncrepl also allows the master nodes to re-synchronize after any downtime
631
* Delta-Syncrepl can be used
410
* Syncrepl also allows the provider nodes to re-synchronize after any downtime
634
413
H4: Arguments against MirrorMode
636
415
* MirrorMode is not what is termed as a Multi-Master solution. This is because
637
writes have to go to one of the mirror nodes at a time
638
* MirrorMode can be termed as Active-Active Hot-Standby, therefor an external
639
server (slapd in proxy mode) or device (hardware load balancer) to manage which
640
master is currently active
641
* While syncrepl can recover from a completely empty database, slapadd is much
643
* Does not provide faster or more scalable write performance (neither could
644
any Multi-Master solution)
416
writes have to go to just one of the mirror nodes at a time
417
* MirrorMode can be termed as Active-Active Hot-Standby, therefore an external
418
server (slapd in proxy mode) or device (hardware load balancer)
419
is needed to manage which provider is currently active
645
420
* Backups are managed slightly differently
646
421
- If backing up the Berkeley database itself and periodically backing up the
647
422
transaction log files, then the same member of the mirror pair needs to be
648
423
used to collect logfiles until the next database backup is taken
649
424
- To ensure that both databases are consistent, each database might have to be
650
425
put in read-only mode while performing a slapcat.
651
- When using slapcat, the generated LDIF files can be rather large. This can
652
happen with a non-MirrorMode deployment also.
426
* Delta-Syncrepl is not yet supported
654
428
For configuration, please see the {{SECT:MirrorMode}} section below
431
H3: Syncrepl Proxy Mode
433
While the LDAP Sync protocol supports both pull- and push-based replication,
434
the push mode (refreshAndPersist) must still be initiated from the consumer
435
before the provider can begin pushing changes. In some network configurations,
436
particularly where firewalls restrict the direction in which connections
437
can be made, a provider-initiated push mode may be needed.
439
This mode can be configured with the aid of the LDAP Backend
440
({{SECT: Backends}} and {{slapd-ldap(8)}}). Instead of running the
441
syncrepl engine on the actual consumer, a slapd-ldap proxy is set up
442
near (or collocated with) the provider that points to the consumer,
443
and the syncrepl engine runs on the proxy.
445
For configuration, please see the {{SECT:Syncrepl Proxy}} section.
449
The old {{slurpd}} mechanism only operated in provider-initiated
450
push mode. Slurpd replication was deprecated in favor of Syncrepl
451
replication and has been completely removed from OpenLDAP 2.4.
453
The slurpd daemon was the original replication mechanism inherited from
454
UMich's LDAP and operated in push mode: the master pushed changes to the
455
slaves. It was replaced for many reasons, in brief:
457
* It was not reliable
458
** It was extremely sensitive to the ordering of records in the replog
459
** It could easily go out of sync, at which point manual intervention was
460
required to resync the slave database with the master directory
461
** It wasn't very tolerant of unavailable servers. If a slave went down
462
for a long time, the replog could grow to a size that was too large for
464
* It only worked in push mode
465
* It required stopping and restarting the master to add new slaves
466
* It only supported single master replication
468
Syncrepl has none of those weaknesses:
470
* Syncrepl is self-synchronizing; you can start with a consumer database
471
in any state from totally empty to fully synced and it will automatically
472
do the right thing to achieve and maintain synchronization
473
** It is completely insensitive to the order in which changes occur
474
** It guarantees convergence between the consumer and the provider
475
content without manual intervention
476
** It can resynchronize regardless of how long a consumer stays out
477
of contact with the provider
478
* Syncrepl can operate in either direction
479
* Consumers can be added at any time without touching anything on the
481
* Multi-master replication is supported
657
484
H2: Configuring the different replication types
1112
923
H4: MirrorMode Summary
1114
Hopefully you will now have a directory architecture that provides all of the
1115
consistency guarantees of single-master replication, whilst also providing the
925
You will now have a directory architecture that provides all of the
926
consistency guarantees of single-master replication, while also providing the
1116
927
high availability of multi-master replication.
932
!import "push-based-complete.png"; align="center"; title="Syncrepl Proxy Mode"
933
FT[align="Center"] Figure X.Y: Replacing slurpd
935
The following example is for a self-contained push-based replication solution:
937
> #######################################################################
938
> # Standard OpenLDAP Master/Provider
939
> #######################################################################
941
> include /usr/local/etc/openldap/schema/core.schema
942
> include /usr/local/etc/openldap/schema/cosine.schema
943
> include /usr/local/etc/openldap/schema/nis.schema
944
> include /usr/local/etc/openldap/schema/inetorgperson.schema
946
> include /usr/local/etc/openldap/slapd.acl
948
> modulepath /usr/local/libexec/openldap
949
> moduleload back_hdb.la
950
> moduleload syncprov.la
951
> moduleload back_monitor.la
952
> moduleload back_ldap.la
954
> pidfile /usr/local/var/slapd.pid
955
> argsfile /usr/local/var/slapd.args
957
> loglevel sync stats
960
> suffix "dc=suretecsystems,dc=com"
961
> directory /usr/local/var/openldap-data
967
> index objectClass eq
971
> rootdn "cn=admin,dc=suretecsystems,dc=com"
974
> # syncprov specific indexing
978
> # syncrepl Provider for primary db
980
> syncprov-checkpoint 1000 60
982
> # Let the replica DN have limitless searches
983
> limits dn.exact="cn=replicator,dc=suretecsystems,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
990
> ##############################################################################
991
> # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
992
> ##############################################################################
995
> # ignore conflicts with other databases, as we need to push out to same suffix
997
> suffix "dc=suretecsystems,dc=com"
998
> rootdn "cn=slapd-ldap"
999
> uri ldap://localhost:9012/
1003
> # We don't need any access to this DSA
1006
> acl-bind bindmethod=simple
1007
> binddn="cn=replicator,dc=suretecsystems,dc=com"
1008
> credentials=testing
1011
> provider=ldap://localhost:9011/
1012
> binddn="cn=replicator,dc=suretecsystems,dc=com"
1014
> credentials=testing
1015
> searchbase="dc=suretecsystems,dc=com"
1016
> type=refreshAndPersist
1021
A replica configuration for this type of setup could be:
1023
> #######################################################################
1024
> # Standard OpenLDAP Slave without Syncrepl
1025
> #######################################################################
1027
> include /usr/local/etc/openldap/schema/core.schema
1028
> include /usr/local/etc/openldap/schema/cosine.schema
1029
> include /usr/local/etc/openldap/schema/nis.schema
1030
> include /usr/local/etc/openldap/schema/inetorgperson.schema
1032
> include /usr/local/etc/openldap/slapd.acl
1034
> modulepath /usr/local/libexec/openldap
1035
> moduleload back_hdb.la
1036
> moduleload syncprov.la
1037
> moduleload back_monitor.la
1038
> moduleload back_ldap.la
1040
> pidfile /usr/local/var/slapd.pid
1041
> argsfile /usr/local/var/slapd.args
1043
> loglevel sync stats
1046
> suffix "dc=suretecsystems,dc=com"
1047
> directory /usr/local/var/openldap-slave/data
1051
> idlcachesize 10000
1053
> index objectClass eq
1057
> rootdn "cn=admin,dc=suretecsystems,dc=com"
1060
> # Let the replica DN have limitless searches
1061
> limits dn.exact="cn=replicator,dc=suretecsystems,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
1063
> updatedn "cn=replicator,dc=suretecsystems,dc=com"
1065
> # Refer updates to the master
1066
> updateref ldap://localhost:9011
1073
You can see we use the {{updatedn}} directive here and example ACLs ({{F:usr/local/etc/openldap/slapd.acl}}) for this could be:
1075
> # Give the replica DN unlimited read access. This ACL may need to be
1076
> # merged with other ACL statements.
1079
> by dn.base="cn=replicator,dc=suretecsystems,dc=com" write
1082
> access to dn.base=""
1085
> access to dn.base="cn=Subschema"
1088
> access to dn.subtree="cn=Monitor"
1089
> by dn.exact="uid=admin,dc=suretecsystems,dc=com" write
1097
In order to support more replicas, just add more {{database ldap}} sections and
1098
increment the {{syncrepl rid}} number accordingly.
1100
Note: You must populate the Master and Slave directories with the same data,
1101
unlike when using normal Syncrepl
1103
If you do not have access to modify the master directory configuration you can
1104
configure a standalone ldap proxy, which might look like:
1106
!import "push-based-standalone.png"; align="center"; title="Syncrepl Standalone Proxy Mode"
1107
FT[align="Center"] Figure X.Y: Replacing slurpd with a standalone version
1109
The following configuration is an example of a standalone LDAP Proxy:
1111
> include /usr/local/etc/openldap/schema/core.schema
1112
> include /usr/local/etc/openldap/schema/cosine.schema
1113
> include /usr/local/etc/openldap/schema/nis.schema
1114
> include /usr/local/etc/openldap/schema/inetorgperson.schema
1116
> include /usr/local/etc/openldap/slapd.acl
1118
> modulepath /usr/local/libexec/openldap
1119
> moduleload syncprov.la
1120
> moduleload back_ldap.la
1122
> ##############################################################################
1123
> # Consumer Proxy that pulls in data via Syncrepl and pushes out via slapd-ldap
1124
> ##############################################################################
1127
> # ignore conflicts with other databases, as we need to push out to same suffix
1129
> suffix "dc=suretecsystems,dc=com"
1130
> rootdn "cn=slapd-ldap"
1131
> uri ldap://localhost:9012/
1135
> # We don't need any access to this DSA
1138
> acl-bind bindmethod=simple
1139
> binddn="cn=replicator,dc=suretecsystems,dc=com"
1140
> credentials=testing
1143
> provider=ldap://localhost:9011/
1144
> binddn="cn=replicator,dc=suretecsystems,dc=com"
1146
> credentials=testing
1147
> searchbase="dc=suretecsystems,dc=com"
1148
> type=refreshAndPersist
1153
As you can see, you can let your imagination go wild using Syncrepl and
1154
{{slapd-ldap(8)}} tailoring your replication to fit your specific network
added
removed
doc/guide/admin/replication.sdf
