slurpd replicatoin problems

["John Hogenmiller" <john@pennswoods.net>]

Hello,

I am in the process of upgrading our ldap servers to openldap 2.1.5.

Our setup:

1 master ldap server behind a firewall.
4 slave ldap servers in remote locations

stunnel is setup to securely transmit ldap changes from the master ldap
server to the remote ldap servers.  We have maintained this setup
peacefully for two years (the only change being moving from ugly ssh
tunnels to the cleaner stunnel).

Recently, I have begun upgrading these boxes from 2.0.xx versions to 2.1.5
I upgraded one box to the new version, and it immediately stopped taking
new updates from our master ldap server.  It would accept type:
modification, but not type: add.  Each addition would be rejected with the
message "type or value already exists".  An ldapsearch showed the object
didn't exist, and using ldapadd would successfully insert the rejected
entry.  At this time, we were running openldap 1.1.13-eng on the master
ldap server and I suspected the version discrprency as the culprit.

Because we were planning on upgrading everything, I setup openldap 2.1.5
on the master ldap server and worked with it till I had it replicating to
both 2.0.xx (18-21) servers, and the 2.1.5 server.  Once I had everything
setup, I switched everything over to using the 2.1.5 server. (On a fresh
install of redhat 7.3, db-4.1.24).

The remote ldap server (slave0) with openldap 2.1.5 also has a fresh
install of redhat 7.3, db-4.1.24.  I created an additional slave (slave1)
with the exact same configuration and put it in place.

Now, when slurpd on master does a replication, it succeeds in replicating
to slave0, slave2, and slave3 (slave2 and slave3 are older versions of
ldap and linux).  When it goes to make an addition to slave1, I get the
following error in openldap-slurpd/replica/localhost:4005.ref:

ERROR: Type or value exists
replica: localhost:4005
time: 1034142867.0
dn: uid=testjp7,ou=people,dc=pennswoods,dc=net
changetype: add
gecos: test test
.. <remaining ldap entry>

This is the same exact problem I had when the master running 1.1.13eng was
attempting to replicate to slave0 running 2.1.5.

This is not an issue where I am sending the same add twice to the same
server.  I checked this out thoroughly.  The stunnel's are pointing at the
right server, no two are going to the same server, and they are listening
on the right port, as defined in slapd.conf.  And no, the dn does not
exist on the remote server, never did, and doesn't until I run slapadd
directly (either contacting the remote server directly, or over the
stunnel).

I've been searching the mailling list for anyone with similiar problems
and haven't seen anything more recent than 2 years ago, and the
problem/solution did not match my scenario.

At this point, I have exhausted my knowledge of where to look.  I can
provid e configuration files, debug logs, etc.  If this is a problem with
the underlying database (db-4.1.24), let me know.  I feel this is a
problem with slurpd, as ldapadd works perfectly fine processing these .rej
files (after eliminating a few extraneous lines that slurpd uses).

Thanks in advance for any help you can provide.

Cheers,
John


-- 
John Hogenmiller, kb3dfz
Network Engineer
Pennswoods.net
877.716.2002 x 529