[Date Prev][Date Next] [Chronological] [Thread] [Top]

updateref question and Openldap Replication

Many thanks to Justin Hahn who helped me solve a great portion of getting replication to work on our test systems.
For those of you who maybe stuck, you may find the section at the bottom of this e-mail helpful.

My question is centered around the updateref and how it performs its job.

Currently updateref is defined to be ldap://153.32.1.120:389

updateref[TAB]"ldap://153.32.1.120:389"; or
updateref	"ldap://153.32.1.120:389";

Whenever I send a request to update/delete a member from a group to the master, everything works as expected. The replication is sent to the slave and everything is fine. When I send an update to the slave however, I get a Referral but the changes never make it to the master. Here are the steps I've taken:

(1) /usr/local/bin/ldapmodify -f mod.ldif -v -d 256 -h "myslave.mydomain.com" -p "389" -D "cn=admin,o=MyDomain" -w adminpw

(2) output is:
ber_flush: 45 bytes to sd 5
request 1 done
add remove:
	member
add member:
	uid=testAccount1@test.org,ou=External_ID,ou=Company,o=MyDomain
modifying entry "cn=testGroup, ou=SpecialGroup, ou=Company, o=MyDomain"
ber_flush: 169 bytes to sd 5
ldap_modify: Referral

ldif_record() = 10
ber_flush: 7 bytes to sd 5

(3) I tested the network connection everything is fine
telnet myslave.mydomain.com 389

and the response on the master logs are:
Oct 31 12:33:10 myslave slapd[3515]: daemon: conn=81 fd=31 connection from IP=15.32.1.121:33376 (IP=0.0.0.0:0) accepted

so it looks like I can telnet into the port no problem. Since the boxes don't have a browser with them (we can only telnet) there's no other way I could think of to test that the "referral" is actually being passed onto the master.

Can anybody offer any suggestions???

Thanks in advance.



#############################################
#
Configuring Replication tips one master, one slave
1. If best, start with two identical machines. To achieve this, install OpenLDAP on one, configure slapd.conf, install the data (index it if necessary) and then tar up this build and copy it over to the intended slave.
2. Make sure to create a replicator account (other than root) on both the master and the slave such that when you copy your databases over to the slave, this account already exists
3. In the slapd.conf, I modify the section beneath the ldbm database section as follows for the master

#######################################################################
# ldbm database definitions
#######################################################################

database ldbm
cachesize 1000
dbcachesize 100000
dbnolocking
dbnosync
directory /ldapdb # directory for all your LDAP data make sure that this is owned by slapd (user you create) and chmod at least 600
suffix "o=MyDomain" # some examples could be "o=Hewlett-Packard" etc
rootdn "cn=root,o=MyDomain"
rootpw secret

# replication
replica host=myslave.mydomain.com:389
binddn="cn=MyCopier, o=MyDomain" # Make sure that this account has a space between MyCopier, and o=MyDomain
bindmethod=simple credentials=123abc # credentials
replogfile /replication/replication.log # Make sure that slapd has access to this for testing purposes

# ldbm indexed attribute definitions ###################################
index default pres,eq
index objectClass,uid
index cn,sn eq,sub

4. In the slapd.conf of the slave, the ldbm database definitions are the safe with the exception of the replication section

#######################################################################
# ldbm database definitions
#######################################################################

database ldbm
cachesize 1000
dbcachesize 100000
dbnolocking
dbnosync
directory /ldapdb # directory for all your LDAP data make sure that this is owned by slapd (user you create) and chmod at least 600
suffix "o=MyDomain" # some examples could be "o=Hewlett-Packard" etc
rootdn "cn=root,o=MyDomain"
rootpw secret

# replication
updatedn "cn=MyCopier, o=MyDomain" # make sure that there is a space between MyCopier, and o=MyDomain
updateref "ldap://mymaster.mydomain.com:389"; # your master server

# ldbm indexed attribute definitions ###################################
index default pres,eq
index objectClass,uid
index cn,sn eq,sub

5. Start slapd and slurpd on the master, here's a shell script that I wrote that might help you (Solaris 2.7 Bourne Shell)
#!/bin/sh

DEBUG_MODE=256

case "$1" in
   'start')
        # Start the slapd daemon
        if [ -f /usr/local/libexec/slapd ] ; then
          echo "starting slapd"
          /usr/local/libexec/slapd \
          -f /usr/local/etc/openldap/slapd.conf \
          -h "ldap:/// ldaps:///" \
          -l local4 \
          -s $DEBUG_MODE \
          -u slapd -g slapd

# If the slapd daemon started fine, start replication
if [ $? = 0 ]; then
if [ -f /usr/local/libexec/slurpd ]; then
echo "starting slurpd"
/usr/local/libexec/slurpd \
-f /usr/local/etc/openldap/slapd.conf
if [ $? = 0 ]; then
nawk 'BEGIN{ "ps -e -o pid,comm | grep slurpd" | getline d; split(d,arr) ; print arr[1]}' > /usr/local/var/slurpd.pid
fi
fi
fi
fi
;;
'stop')
# Stop the slapd daemon
echo "stopping slapd"
kill -TERM `cat /usr/local/var/slapd.pid`
echo "stopping slurpd"
kill -TERM `cat /usr/local/var/slurpd.pid`
;;

6. Always do a /bin/ps -ef | grep sl to make sure everything is running properly, your output should be similar to:

slapd 3515 1 0 11:31:05 ? 0:32 /usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf -h ldap:/// ldap
root 3517 1 0 11:31:05 ? 0:00 /usr/local/libexec/slurpd -f /usr/local/etc/openldap/slapd.conf

7. Start slapd on the slave (not slurpd)

8. Send an update to the master and you should see that everything is replicating fine. If it doesn't, make sure that you've defined the proper access control rules for the MyCopier account. Also check that you have all your file permissions straightened away.

Hope this helps for anyone, who's been scratching their heads (as I have for a while) trying to get replication working. Good luck!

OpenLDAP 2.0.11
db-3.2.9
OpenSSL-0.9.6b
Solaris 2.7