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?

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

Yes, that surprises me. Slave tells that it will refer the change to master, but master does not receive any information. I use debug level -1, but cannot find the change arrives in master.

I forget the exact arguments you used, but it's probably your job to follow the referral. i.e., you should be running ldapmodify -H ldap://master/...

But certainly if you're not seeing the change at the master you can't be surprised that it's not at a slave!

access to * by * write

That's awfully permissive; most sites would consider a least privilege model as a Good Idea. Of course Your Needs May Vary.

It succeeded in adding group.ldif to master. After the master changes, the group.ldif also replicates to slave.

Sounds good.

Result: adding new entry "ou=groups,dc=mycompany,dc=com" ldapadd: Referral (10) referrals: ldap://master.server:389/ou=groups,dc=mycompany,dc=com [...] How can I trace the referral? Thank you.

No, that's the end, nothing to trace. That is, the URI printed above -- that is the referral -- end of story. All working properly at this point. It's the client's job to decide what to do with the referral. In the case of OpenLDAP clients, it prints it, nothing more.

You may code a custom client that handles the referral, if you desire. (Hopefully this would be locked down to ensure that it only talks to your trusted servers. The inability to determine if a server is trusted or untrusted is why referral chasing is not supported with OpenLDAP clients.)

Another idea would be to use the slapo-chain examples described on this list, e.g. http://www.openldap.org/lists/openldap-software/200709/msg00054.html. Since the slapo-chain will only go to the explicitly configured URI you trust, it may be construed as safer than having clients jump around randomly.

Turn your server debugging to 16512 (128+16384). Watch your logs form the server to see what it's doing when you make changes. Like I said before, it's gotta be an ACL

Sellers

On Apr 23, 2008, at 11:49 AM, Jacky Wu wrote:

On Wed, Apr 23, 2008 at 10:37 PM, Aaron Richton <richton@nbcs.rutgers.edu

...

wrote:

          updatedn="uid=repl_writer,dc=mycompany,dc=com"

I don't think this is valid. Try "slaptest -d config" and/or read slapd.conf(5) man page.

Even though I cannot find the updatedn from syncrepl directory, I copy this from this mailing list. I use debug -d -1, and it do not report error.

*The userpassword does not replicate to slave. *The following is the replicated result in slave.

If you modify one of the other attributes (cn/sn/etc.), does it make it from the master to the slave?

Yes, other attributes replicates.

Turn up debugging and see what's going on. I'd look for ACL issues first. Are those really your only two access rules?

ldapmodify: Referral (10) referrals:

ldap://master:389/uid=testuser,dc=mycompany,dc=com<ldap://master:389/uid=repl_reader,dc=ufreight,dc=com

...

This isn't a problem -- the slave is telling you it's a slave and you should be talking to the master. So that's a sign that your config is on the right track.

Yes, that surprises me. Slave tells that it will refer the change to master, but master does not receive any information. I use debug level -1, but cannot find the change arrives in master.

-- 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