[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Openldap V2 replication
Hi,
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.
Hth,
Dejan
Please respond to Patrice Lallement <cyberpl@noos.fr>
Sent by: owner-openldap-software@OpenLDAP.org
To: openldap-software@OpenLDAP.org
cc:
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
wrong?
Before reading every RFC regarding LDAP V3, I will be very glad to have
some tips about replication.
Thanks in advance,
Patrice