In certain configurations, a single {{slapd}}(8) instance may be
insufficient to handle the number of clients requiring
directory service via LDAP. It may become necessary to
-run more than one slapd instance. Many sites,
-for instance, there are multiple slapd servers, one
+run more than one slapd instance. At many sites,
+for instance, there are multiple slapd servers: one
master and one or more slaves. {{TERM:DNS}} can be setup such that
a lookup of {{EX:ldap.example.com}} returns the {{TERM:IP}} addresses
of these servers, distributing the load among them (or
> replica: slave.example.com:389
> time: 809618633
-> dn: uid=bjensen, dc=example, dc=com
+> dn: uid=bjensen,dc=example,dc=com
> changetype: modify
> replace: multiLineDescription
> description: A dreamer...
> -
> replace: modifiersName
-> modifiersName: uid=bjensen, dc=example, dc=com
+> modifiersName: uid=bjensen,dc=example,dc=com
> -
> replace: modifyTimestamp
> modifyTimestamp: 20000805073308Z
This option sets the slurpd debug level to {{EX: <level>}}. When
level is a `?' character, the various debugging levels are
-printed and slapd exits, regardless of any other options
+printed and slurpd exits, regardless of any other options
you give it. Current debugging levels (a subset of slapd's
debugging levels) are
-> 4 heavy trace debugging
-> 64 configuration file processing
-> 65535 enable all debugging
+!block table; colaligns="RL"; align=Center; \
+ title="Table 13.1: Debugging Levels"
+Level Description
+4 heavy trace debugging
+64 configuration file processing
+65535 enable all debugging
+!endblock
Debugging levels are additive. That is, if you want heavy
trace debugging and want to watch the config file being
> -t <directory>
-Specify an alternate directory for slurpd's temporary
-copies of replication logs. The default location is /usr/tmp.
+Specify an alternate directory for slurpd's temporary copies of
+replication logs. The default location is {{F:/usr/tmp}}.
H2: Configuring slurpd and a slave slapd instance
+ Do not include a {{EX:replogfile}} directive.
-+ Do include an updatedn line. The DN given should
++ Do include an {{EX:updatedn}} line. The DN given should
match the DN given in the {{EX:binddn=}} parameter of the
corresponding {{EX:replica=}} directive in the master slapd
config file.
permission to write the database (e.g., it is listed as {{EX:rootdn}}
or is allowed {{EX:access}} by one or more access directives).
++ Use the {{EX:updateref}} directive to define the URL the
+slave should return if an update request is received.
H3: Shut down the master {{slapd}}
H3: Copy the master slapd's database to the slave
-Copy the master's database(s) to the slave. For an
-{{TERM:LDBM}}-based database, you must copy all database
-files located in the database {{EX:directory}} specified in
-{{slapd.conf}}(5). Database files will have a different
-suffix depending on the underlying database package used.
-The current possibilities are
+Copy the master's database(s) to the slave. For an {{TERM:BDB}} and
+{{TERM:LDBM}} databases, you must copy all database files located
+in the database {{EX:directory}} specified in {{slapd.conf}}(5).
+In general, you should copy each file found in the database {{EX:
+directory}} unless you know it is not used by {{slapd}}(8).
-* {{EX: dbb}} Berkeley DB B-tree backend
-* {{EX: dbh}} Berkeley DB hash backend
-* {{EX: gdbm}} GNU DBM backend
-
-In general, you should copy all files found in the database
-{{EX: directory}} unless you know it not used by {{slapd}}(8).
-
-Note: The copy process assumes homogeneous servers with
-identically configured OpenLDAP installations.
+Note: This copy process assumes homogeneous servers with
+identically configured OpenLDAP installations. Alternatively,
+you may use {{slapcat}} to output the master's database in LDIF
+format and use the LDIF with {{slapadd}} to populate the
+slave. Using LDIF avoids any potential incompatibilities due
+to differing server architectures or software configurations.
+See the {{SECT:Database Creation and Maintenance Tools}}
+chapter for details on these tools.
H3: Configure the master slapd for replication
process will bind to the slave slapd as
"{{EX:cn=Replicator,dc=example,dc=com}}" using simple authentication
with password "{{EX:secret}}". Note that the DN given by the {{EX:binddn=}}
-directive must either exist in the slave slapd's database (or be
+directive must exist in the slave slapd's database (or be
the rootdn specified in the slapd config file) in order for the
bind operation to succeed. The DN should also be listed as
the {{EX:updatedn}} for the database in the slave's slapd.conf(5).
When slurpd propagates a change to a slave slapd and
receives an error return code, it writes the reason for the
error and the replication record to a reject file. The reject
-file is located in the same directory with the per-replica
+file is located in the same directory as the per-replica
replication logfile, and has the same name, but with the
string "{{F:.rej}}" appended. For example, for a replica running
on host {{EX:slave.example.com}}, port 389, the reject file, if it
exists, will be named
-> /usr/local/var/openldap/replog.slave.example.com:389.
+> /usr/local/var/openldap/replog.slave.example.com:389.rej
A sample rejection log entry follows:
> ERROR: No such attribute
> replica: slave.example.com:389
> time: 809618633
-> dn: uid=bjensen, dc=example, dc=com
+> dn: uid=bjensen,dc=example,dc=com
> changetype: modify
> replace: description
> description: A dreamer...
> -
> replace: modifiersName
-> modifiersName: uid=bjensen, dc=example, dc=com
+> modifiersName: uid=bjensen,dc=example,dc=com
> -
> replace: modifyTimestamp
> modifyTimestamp: 20000805073308Z
> slurpd -r /usr/tmp/replog.slave.example.com:389 -o
+!if 0
H2: Replication to an X.500 DSA
!import "replication.gif"; align="center"; \
title="Replication from slapd to an X.500 DSA"
-FT: Figure 6: Replication from slapd to an X.500 DSA
+FT: Figure 10.1: Replication from slapd to an X.500 DSA
Note that the X.500 DSA must be a read-only copy. Since
the replication is one-way, updates from {{TERM:DAP}} clients
{{EX:lastModifiedBy}} and {{EX:lastModifiedTime}}.
A solution to this attribute naming problem is to have the
-ldapd read oidtables that map {{EX:modifiersName}} to the
-objectID (OID) for the {{EX:lastModifiedBy}} attribute and
-{{EX:modifyTimeStamp}} to the OID for the {{EX:lastModifiedTime}}
-attribute. Since attribute names are carried as OIDs over
-DAP, this should perform the appropriate translation of
-attribute names.
+LDAP/DAP gateway to map {{EX:modifiersName}} to the Object
+Identifier ({{TERM:OID}}) for the {{EX:lastModifiedBy}}
+attribute and {{EX:modifyTimeStamp}} to the OID for the
+{{EX:lastModifiedTime}} attribute. Since attribute names
+are carried as OIDs over DAP, this should perform the
+appropriate translation of attribute names.
+
+!endif
projects / openldap / blobdiff