Re: Fail to write in slave during replication

[Gavin Henry <ghenry@OpenLDAP.org>]

Jacky Wu wrote:
> Dear Sellers,
>
> Thank you.  Yes, it is the ACL problem. When I set  following access on 
> both master and slave
>
> access to *
>    by * write
>
> The attribute userpassword is replicated to slave.
>
> But the change in the slave still cannot be replicated to master, and 
> the slave does not change either. Still no error or exception is reported.
>
> I want to add following ldif:
> dn: ou=groups,dc=mycompany,dc=com
> objectclass: organizationalunit
> ou: groups
>
>
> I used the 16512 debug level, but I do not find any exception in slave. 
> the slave slapd.log shows:
> Apr 25 08:41:57 slave slapd[29230]: conn=1 op=0 BIND 
> dn="uid=myname,dc=mycompany,dc=com" mech=SIMPLE ssf=0
> Apr 25 08:41:57 slave slapd[29230]: conn=1 op=1 ADD 
> dn="ou=groups,dc=mycompany,dc=com"
> Apr 25 08:41:57 slave slapd[29230]: conn=1 op=1 RESULT tag=105 err=10 text=

Like in your first post, it's not an error, it's a referral:

>>     The following is the running result:
>>     ****************************************************************
>>     modifying entry "uid=testuser,dc=mycompany,dc=com"
>>     ldapmodify: Referral (10)
>>             referrals:
>>                     ldap://master:389/uid=testuser,dc=mycompany,dc=com
>>      ****************************************************************


The slave doesn't take writes, it refers the client to the Master. "I 
don't accept writes, speak to 
ldap://master:389/uid=testuser,dc=mycompany,dc=com"; etc.

You can use slapo-chain to send writes back to the master from the 
slave, or use MirrorMode or N-Way Multimaster.

What are you trying to achieve with your current network layout?


--
Kind Regards,

Gavin Henry.
OpenLDAP Engineering Team.

E ghenry@OpenLDAP.org

Community developed LDAP software.

http://www.openldap.org/project/