Replication between 2.2 and 2.0

["Chris Robertson" <crobertson@gci.com>]

Sorry in advance.  This message is going to be a bit long.

I have about 140 sites, spread across about 20 divisions, underneath a single company.  We are staring an upgrade of servers, but said upgrade is disruptive and is going to take some time (possibly years).  The old servers are running OpenLDAP 2.0 (2.0.23 to be exact), and the new servers are (going to be) running 2.2(.13).

Blithely unaware, I set up a new server as a test, and tried to get it to replicate data from the central LDAP server (2.0.27).  This did not work.  So I did a bit of research and found the schism between OpenLDAP 2.0 and 2.2, with a hopeful note that replication from a 2.2 master to a 2.0 slave should be possible (http://www.openldap.org/lists/openldap-software/200505/msg00340.html).

I set up a test using 2.2 as the master and 2.0 as the slave, with a replica directive including "attr!=structuralObjectClass,entryUUID,entryCSN".  Replication failed, and the reject file showed "ERROR: Constraint violation: creatorsName: no user modification allowed".  Fair enough.  I expanded the attr line to include "creatorsName,createTimestamp,modifiersName,modifyTimestamp".

Now replication is still failing, with an error of...

ERROR: Type or value exists: attribute provided more than once
replica: slave.example.org:389
time: 1123878942.3
dn: uid=tuser,dc=site,dc=division,dc=company,dc=com
changetype: add
cn: Test User
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Division
givenName: Test
sn: User
uid: tuser
l: Division
userPassword:: BLANKED
userPassword:: BLANKED
mail: tuser@site.division.company.com
mail: test.user@site.division.company.com

...and I'm at a bit of a loss.  Searching for the error message gave me http://www.openldap.org/lists/openldap-software/200206/msg00083.html which is (to the best of my knowledge) not applicable here.  Creating an ldif file on the 2.0 slave containing...

dn: uid=tuser,dc=site,dc=division,dc=company,dc=com
cn: Test User
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Staff
givenName: Test
sn: User
uid: tuser
l: Division
userPassword:: BLANKED
userPassword:: BLANKED
mail: tuser@site.division.company.com
mail: test.user@site.division.company.com

...and using ldapadd (authenticating as the Replication user) works just fine (the LDAP entry is created, as evidenced by a search).

Any help or suggestions would be greatly appreciated.  While I imagine it would be possible to run two LDAP servers for the duration of the migration (perhaps using LDAPproxy to give a unified front) I see that as a last resort.

Chris