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

Re: Fail to write in slave during replication

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.