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

Re: Fail to write in slave during replication



Jacky,
Glad you determined the ACL.  Now, you have to pair down the access to be a little more restrictive.  But now that you see it was the ACL, you can focus on that.  Remember order matters.  

As for the referrals, as Aaron mentioned, try a different client.  Apache has a directory client, I've used that and found it very handy.  There is also LDAPBrowser.  Google those and you should see results.  Also, make sure your client can resolve the ldap url and hostname. (I notice you don't have fully qualified names in the list, which may be to protect yourself from attacking but something to check in case you didn't scrub to post on the list)

Sellers

On Apr 24, 2008, at 9:52 PM, 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=

Any other hints? Thank you.

Best regards,
Jacky




On Wed, Apr 23, 2008 at 10:28 PM, Chris G. Sellers <chris.sellers@nitle.org> wrote:
Your replication problem I feel you have an ACL problem.  userPassword is often governed by it's own ACL in the .access.conf file.   Make sure your replication user will use that ACL.  Also, check priority in ACLs.  There is an order in which they are applied.  It's documented in the manual pages and in the Admin guides online.


Your referral update problem is related the above problem.  You can never update a slave, and since the replication can not update the slave, you will never get a userPassword attribute.   Fix the replication first, and then regroup and attack the second problem.

Turn your LDAP logging up too and you should see the error more explicitly. 

Sellers


On Apr 23, 2008, at 3:34 AM, Jacky Wu wrote:

Dear all,
 
I set up my replication using syncrepl in 2.3.38. The setting is
 
slave
*****************************************************************
syncrepl rid=123
                provider=ldap://master:389
                type=refreshOnly
                interval=00:00:00:20
                searchbase="dc=mycompany,dc=com"
                schemachecking=on
                updatedn="uid=repl_writer,dc=mycompany,dc=com"
                bindmethod=simple
                binddn="uid=repl_reader,dc=mycompany,dc=com"
                credentials=secret
 
updateref  ldap://master:389
 
access to *
  by dn.exact="uid=repl_writer,dc=mycompany,dc=com" write 
        by dn.exact="uid=repl_reader,dc=mycompany,dc=com" read
****************************************************************
 
 
master:
****************************************************************
overlay         syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
 
access to *
  by dn.exact="uid=repl_writer,dc=mycompany,dc=com" write 
        by dn.exact="uid=repl_reader,dc=mycompany,dc=com" read
****************************************************************
 
 
Problem 1:
When I add following user in master:
****************************************************************
dn: uid=testuser,dc=mycompany,dc=com
objectclass: inetorgperson
uid: testuser
cn: cn
sn: sn
userpassword: secret
****************************************************************
 
The userpassword does not replicate to slave. The following is the replicated result in slave.
****************************************************************
# testuser, mycompany.com
dn: uid=testuser,dc=mycompany,dc=com
objectClass: inetOrgPerson
uid: testuser
cn: cn
sn: sn
****************************************************************
 
 
 
Problem 2:
Since the userpassword is missing in the entry, I want to add it in slave by manual.
    ldapmodify   -x   -D "cn=admin,dc=mycompany,dc=com" -w secret -f  /tmp/userpassword.ldif
 
The /tmp/userpassword.ldif is
****************************************************************
dn: uid=testuser,dc=mycompany,dc=com
changetype: modify
add: userPassword
userPassword:  NewSecret
****************************************************************
 
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
 ****************************************************************

Even though the result shows that it will update master by referral,  the userpassword in master does not change, and the testuser in slave still do not have attribute userpassword.

After studying the replication configuration, and trying to search the mailist archive, I still do not know how to solve the problem.
 
Thank you.
 
Best regards,
Jacky


--
John 3:16 For God so loved the world, that He gave His only begotten Son, that whoever believes in Him shall not perish, but have eternal life.
http://www.hkccc.org/flash2.htm

______________________________________________
Chris G. Sellers | NITLE  - Technology Team
AIM: imthewherd | GoogleTalk: cgseller@gmail.com




--
John 3:16 For God so loved the world, that He gave His only begotten Son, that whoever believes in Him shall not perish, but have eternal life.
http://www.hkccc.org/flash2.htm

______________________________________________
Chris G. Sellers | NITLE  - Technology Team
AIM: imthewherd | GoogleTalk: cgseller@gmail.com