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

Re: Openldap V2 replication


1. Chasing referrals is partly supported in ldap utilities.  The behaviour 
you see (anon bind on rebind) is a default behaviour when there is no 
rebind procedure defined in the application.  In other words, chasing 
referrals depends on how the application was programmed.

2.  Hmm, what do you mean by "from slave to master".  There shouldn't be 
any "from slave to master".

3.  The slave db should be read only and you should use a dn different 
from rootdn for replication.  That way you can differentiate the two in 
ACL.  To recap, the problem is not ACL, but inappropriate referral 
chasing.  You have to find another application instead of ldapmodify.



Please respond to Patrice Lallement <cyberpl@noos.fr> 
Sent by:        owner-openldap-software@OpenLDAP.org
To:     openldap-software@OpenLDAP.org
Subject:        Openldap V2 replication

I just installed openldap 2.0.23 on two machines for replication testing. 
I followed the procedure describes in the openldap administration guide 
and everything is working OK (nearly :)  )

- replication from master to slave works fine
- but from slave to master I have to defined a very permissive acl (access 
to * by * write). Because I'm using ldapmodify as ldap client I also need 
to use the -C switch in order to chase the master (without this switch, 
I've got a referral error : ldif_record() = 10 and the slave doesn't even 
try to contact the master). So this is working but it's not good for a 
production site.

My updatedn in the slapd.conf slave file is the rootdn of both ldap 
servers (master and slave) with the same password. But when I'm using 
ldapmodify the replication process from slave to master bind anonymoulsy 
(?). I thought that the updatedn was used for the bind process. Am I 
Before reading every RFC regarding LDAP V3, I will be very glad to have 
some tips about replication.

Thanks in advance,