This chapter aims to give end users working configurations examples. We provide 3 different replication technologies which can be put in place in order to achieve high availability. Slurpd, syncrepl and its successor delta syncrepl.

It is necessary to use LDAP as our database backend for Samba when using Backup Domain Controllers. This is the recommended design to replicate records to BDC(s).

There are two methods for providing replication, the first and original design was using openldap’s “slurpd” to provide Master / Slave operation, the database is pushed to slaves defined in slapd.conf on the master LDAP server; here is an example of the original way defined in 2.2. slapd.conf Master slurpd.

In order to bind to the database, the slave replicas will need to use “syncusers’s” password defined above as “credentials=SyncUser“. Initially, you'll need to populate the slave database as a manual step as defined in section 3.5 Database Replication.

Openldap 2.2 Original Style Replication Configuration

Master

Slave(s)

A master LDAP database that pushes its database to the slaves providing a persistent connection.

The slave LDAP server requires no additional configuration, as long as it has correct ACLs set in the database and slapd.conf.

The main restriction with using this original design is the ldap database needs to be restarted on both the master and the slave when adding additional replicas. It is also no longer under active development.

In version Openldap 2.3, "delta-syncrepl" was invented as the original syncrepl method used too much network bandwidth. Developers recommend you use the latest version of Openldap (as version 2.2 was decommissioned over a year ago).

The provider LDAP server does not need to be restarted when adding additional slave servers. Configurations will differ depending on your replication methods chosen for syncrepl/delta-syncrepl.

The consumer no longer needs to have its database manually added for initial population. It can request an update at a set interval, or provide a pesistent connection. For persistent connections, delta-syncrepl is the recommended choice. Delta-synrepl was invented as an efficient means for database replication over WAN links where bandwidth was an issue.

These modes of operation are known as syncrepl; which is included in the ldap daemon. This means we no longer need to run the additional slurpd daemon to replicate the database.

On the consumer syncrepl needs to know what mode to operate in: “refeshOnly” operation where the consumer requests an update from the provider at set time interval defined as “interval=00:00:10:00” which would pull the provider every 10 minutes. The more desirable way is to use “refrshAndPersist” which provides a persistant connection. Instead of using a time interval to poll the provider we have the parameter “retry="30 10 300 +" which means it will retry 10 times every 30 seconds, then every 300 seconds if connection is lost; “+” indicates indefinite number of retries.

Fedora 7 now has a bug fix in openldap-2.3.34-3.fc7 id #246036 which means you can now use yum to download the latest openldap and it will include the needed modules so there is no need to compile from source.

We will compile LDAP from source so we can use the latest version of Openldap. When compiling from source, remove any previous versions to avoid complications. Get the latest version of Openldap here http://www.openldap.org/software/download/

Step1.

Extract the contents of the file in a suitable location; I put it in /programs/openldap/release.

[root@node1 release]# tar zxvf openldap-2.3.33.tgz

Step2.

Change to the openldap directory.

[root@node1 release]# cd openldap-2.3.33

Step3.

This will take some time; when it has completed it will ask us to run "make depend"

Create the directories needed as specified in our delta-syncrepl slapd.conf. If you do not create these directories as specified in slapd.conf, you will not be able to start ldap and you will get errors.

You will notice below in the host options that we use both IP addresses of the Primary and Secondary LDAP database servers. This serves as a failover option if the local LDAP database is inaccessible. The same applies for the Slave LDAP configuration; 2.4: ldap.conf Slave

We are now in the source folder, however because there are many different build enviroments available, we must specify we are using some flavour of *Nix.

[root@node1 db-4.5.20]# cd build_unix/
[root@node1 build_unix]#

Step4.

From here we beed to run ../dist/configure so we can build the correct make files. Set the prefix to match our Openldap prefix.

[root@node1 build_unix]# ../dist/configure --prefix=/usr/local

If you get this error it means you are not in the correct build directory.

[root@node1 dist]# ./configure --prefix=/usr/local
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking if building in the top-level or dist directories... yes
configure: error: Berkeley DB should not be built in the top-level or "dist" directories.
Change directory to the build_unix directory and run ../dist/configure from there.
[root@node1 dist]#

Step5.

[root@node1 build_unix]# make

Step6.

The following requires root privileges and will install Berkeley DB onto our system.

[root@node1 build_unix]# make install

Step7.

Now we need to check that our database tools have been installed correctly.