Appendix F: Playing with Replication in OpenLDAP | The ABCs of LDAP: How to Install, Run, and Administer LDAP Services

< Day Day Up >

In this section, we will have a brief look at implementing replication with OpenLDAP. In Chapter 5, I discussed what replication is; in this section, you will have a practical example of how it works. I will implement two LDAP servers: a master server and a slave server. Because not everyone has two computers at their disposal, I have put the master and the slave server on the same machine.

LDAP uses two server daemons to implement a master server: (1) the stand-alone LDAP server daemon called "slapd" and (2) the standalone replication daemon called "slurpd."

When you compile OpenLDAP, you should run the configure script using the switch -enable_slurpd, which tells the configure utility to prepare the makefiles to also produce the replication program; however, this is the default. The slapd master daemon maintains a replication log describing in LDIF format the changes applied to the master directory. The slurpd daemon reads these changes, connects to the slave daemon, and applies these changes to the slave server.

For this example, we will use a highly primitive configuration to concentrate on the concept of replication. We will use only an organization with the DN:

 dc=LdapAbc, dc=org

In this organization, we will add and delete for test purposes a few organizational units.

First of all, we will configure the master server. The rootDN is dc=LdapAbc, dc=org, the DN of the administrator is DN: cn=Administrator, dc=LdapAbc, dc=org. Following is the corresponding database configuration section of the master server.

  26    . . . .  27    # Database Section for : dc=LdapAbc, dc=org  28    database bdb  29    suffix "dc=LdapAbc, dc=org"  30  31    # Administrator Credentials:  32    rootdn "cn=Administrator, dc=LdapAbc, dc=org"  33    rootpw {SSHA}Dh1hgJPc+2akIahgBJyxLAvwc+UXFhg  34

Now we can start the slapd daemon with the usual command:

 ./slapd -f <configuration file>

Once the daemon has started we can add a few objects. Following is the ldapmodify dialog for adding two entries to the master directory; you can put these lines in a file and launch ldapmodify with the -f <filename> switch.

 ldapmodify -D "cn=Administrator,dc=LdapAbc,dc=org" -w "password" DN: dc=LdapAbc, dc=org changetype: add objectclass: top objectclass: dcObject objectclass: organization o: LdapAbc dc: LdapAbc

adding new entry "dc=LdapAbc, dc=org"

 DN: ou=people, dc=LdapAbc, dc=org changetype: add objectclass: top objectclass: organizationalUnit ou: people

adding new entry "ou=peomple,dc=LdapAbc, dc=org

To see that the data has been successfully added, search with the filter

 (objectclass=*).

Once we are done with the master server, we will configure the slave server using the same configuration file. We will have to change the lines pidfile, argsfile, and directory in the slave config-file. The slave server does not yet have a directory. You have two possibilities to mirror the initial directory.

You can copy all the DBM files from the master to the slave.
You can export the master repository in LDIF format using the slapcat command and import it into the slave location using the slapadd command.

When you start the slave server, you should be able to execute searches on it. You should start it on a different port than the master server with the command. I use 689, but you can use a different port provided it is not used by another program (look in /etc/services if you have doubts).

 ./slapd -f <configuration file> -h "ldap://127.0.0.1:689"

Now we have two directory servers, both up and running; however, we need a master server and a slave server. We will first configure the master server, but we must stop both slapd daemons if they are still running.

To configure replication, the slapd daemon needs to know where to dump out the changes applied to the directory. You provide this data to the daemon using the replogfile <filename> directive. Add the following line after the database section:

 replogfile /usr/local/openldap/var/slapd.replog

If you want to put the replication log into another location, substitute <filename> with a file suited to your configuration.

Next, we need to configure the master slurpd daemon. To do this, we can recycle the freshly produced configuration of the slapd daemon, or better still, use the same configuration file, as we will do here. You have only to add the "replica" clause after the replogfile instruction and you are done. In the replogfile, first you specify the LDAP server the slave directory is mounted on. You do this specifying the slave server's LDAP URL, which in our example is ldap://127.0.0.1:689. Next, you configure the part of the directory tree to be replicated, which in our example is the whole tree, i.e., "dc=LdapAbc, dc=org". The rest of the parameters define the authentication of the master server at the slave server. The master connects where binddn is the DN, and the password is "credentials." The bindmethod can be either simple or sasl; we will use simple in our example. The last parameter tls specifies whether the master server should begin a conversation with starttls. In a production environment, you should use TLS; in our example, we do not to keep it simple. Following is the configuration file shared by the master server and the replication server daemon:

     35    # Database Section for : dc=LdapAbc, dc=org     36    database bdb     37    suffix "dc=LdapAbc, dc=org"     38     39    # Administrator Credentials:     40    rootdn "cn=Administrator, dc=LdapAbc,           dc=org"     41    rootpw           {SSHA}Dh1hgJPc+2akIahgBJyxLAvwc+UXFhg     42     43    # Replication Agreement:     44    replogfile           /usr/local/var/openldap/slapd.replog     45    rep       host=127.0.0.1:689           lic           a     46               binddn="cn=replication service,                      dc=LdapAbc, dc=org"     47               bindmethod=simple     48               credentials=password

Once configured, you can start the slapd daemon and test it with a couple of searches. If you update the directory, your updates will be kept in the replication log. As soon as slurpd succeeds in connecting to the slave server, it will also replicate your changes on the master server on the slave server.

Now that the master slapd daemon is up and running, we can proceed with the configuration of the slave slapd daemon. On the slave slapd daemon, you have to configure only two things: (1) the DN the replication process uses to make contacts and (2) the master LDAP server's URL to be used when clients send update requests to the slave server. Once configured, start the slave slapd daemon. Following is the configuration you must add to the slave slapd daemon:

     37    #     38    ## Slave Server Configuration     39     40    # User updates are accepted from     41    updatedn "cn=replication service,           dc=LdapAbc, dc=org"     42     43    ## LDAP URL of the master LDAP server     44    updateref ldap://127.0.0.1     45

At this point, only the replication process is missing. If you modify, add, or delete objects on the master server, you will now see them on the slave LDAP server. For this you must start the slurpd daemon. As soon as you start the slurpd daemon, it will contact the slave server and push the updates mentioned in the replication log to the slave server.

This architecture is used for performance reasons, but can also he integrated into the backup strategy. You shut down the slave server when an offline backup has to be made. All changes in the directory are recorded in the replication log file and replicated as soon as the slave server is online again.

< Day Day Up >