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 734.661.2318 | chris.sellers@nitle.org 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 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GoogleTalk: cgseller@gmail.com