Update on this one. After I re-configured the replication, it works!
However, when I set the replication up over LDAPS, I still run into this issue:
dn: cn="o=BASE",cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: "o=BASE"
nsslapd-state: referral on update
nsslapd-referral: ldaps://master:636/o=BASE
 
....
 
dn: cn=replica,cn="o=BASE",cn=mapping tree,cn=config
nsDS5ReplicaBindDN: ...
nsDS5ReplicaRoot: ...
nsDS5Flags: 0
nsDS5ReplicaType: 2
objectClass: top
objectClass: nsDS5Replica
cn: replica
nsDS5ReplicaId: 65535
nsState:: //8AAAAAAADe1w9MAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: 7e703682-73f111df-8ea9acd4-bef98622
nsDS5ReplicaReferral:
ldaps://master:636/o=BASE

Now, I still get this operational error
 
Does someone have a ldaps replication (master - slave) running, where the referrals do work?
 
Thanks,
-Reinhard


From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Reinhard Nappert
Sent: Friday, June 04, 2010 4:49 PM
To: General discussion list for the 389 Directory server project.
Subject: [389-users] Referral not working...

Hi,
 
I configured a master slave setup where the userRoot db has an referral to the master configured. See dse.lif entry:
 
dn: cn="o=BASE",cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: "o=BASE"
nsslapd-state: referral on update
nsslapd-backend: userRoot
modifiersName: cn=server,cn=plugins,cn=config
modifyTimestamp: 20100604203934Z
nsslapd-referral: ldap://master:389/o= BASE 
numSubordinates: 1
So, when I access the slave and try to add an object, I get the following error:

javax.naming.NamingException: [LDAP: error code 1 - Mapping tree node for o=base is set to return a referral, but no referral is configured for it].

This is weird, because you clearly see that the referral is configured.

The access file says:

[04/Jun/2010:16:40:18 -0400] conn=16 op=3 ADD dn="ou=test,o=base"
[04/Jun/2010:16:40:18 -0400] conn=16 op=3 RESULT err=10 tag=105 nentries=0 etime=0

This is standard ldap stuff and I know that it worked before.

Any idea?

Thanks,

-Reinhard