Unfortunately, I think the spec is broken here. There's no way for the consumer to record the references it receives, because they're not accompanied by the DN of the entry that triggered the reference. It would have made more sense for the provider to send the references uninterpreted, as regular LDAP entries.
Any suggestions?
-------- Original Message -------- Subject: Re: (ITS#5881) referral problem with refreshAndPersist mode Date: Sat, 24 Jan 2009 05:12:08 GMT From: hyc@symas.com To: openldap-its@openldap.org
joao.alfredo@gmail.com wrote:
Full_Name: João Alfredo Version: 2.4.13 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.189.117.10)
I am using a refreshAndPersist replication mode on OpenLdap 2.4.13.
When I add referral OU on Master, this entrie is not replicate to Consumer.
My test.ldif: dn: ou=MUNICIPIOS,dc=pr ou: MUNICIPIOS ref: ldap://<IP>/ou=MUNICIPIOS,dc=pr objectClass: referral objectClass: extensibleObject dc: MUNICIPIOS
Logs on consumer side: Jan 8 17:50:15 ecelepar10173 slapd[2722]: do_syncrep2: rid=000 reference received error
Interesting, you've found a bug that has been present since syncrepl's code was first written in 2003. The syncrepl code assumes that it will only receive LDAP entries from the provider. But according to RFC4533, references are supposed to be sent as-is and stored by the consumer. The syncprov overlay obeys the spec and sends references correctly.
Howard Chu wrote:
Unfortunately, I think the spec is broken here. There's no way for the consumer to record the references it receives, because they're not accompanied by the DN of the entry that triggered the reference. It would have made more sense for the provider to send the references uninterpreted, as regular LDAP entries.
Any suggestions?
Discussed this a bit with Kurt. The ContentSync protocol is not solely a DSA-DSA sync protocol. When used as such, the consumer is responsible for sending the ManageDSAiT control with its sync request, to make sure that it receives actual entries, and not search references. HEAD has been patched accordingly.
On Sat, Jan 24, 2009 at 3:19 PM, Howard Chu hyc@symas.com wrote:
Unfortunately, I think the spec is broken here. There's no way for the consumer to record the references it receives, because they're not accompanied by the DN of the entry that triggered the reference. It would have made more sense for the provider to send the references uninterpreted, as regular LDAP entries.
Any suggestions?
It would make sense for a syncrepl to send the referral without any modifications or de-referencing, IFF the entity querying is also syncrepl. Because syncrepl is only replicating state of a DIT (it is in itself not really interested in the data a referral might return) and is not and "end user", it should act as if it is "managing" referrals, and not-de-referencing them.
I'm assuming, the intent of a referral is to make a reference to some other data for a "end user", and usually because that data is of a somewhat transient state, or that it is a delegation to another server for which the local server is not authoritative.
I think the referral should be copied without de-referencing by syncrepl, then when a "end user" asks for that same data from the replica (querying the replica to which the entry has been replicated by syncrepl), they will get data de-referenced at the time of thier query, rather than getting some stale re-referenced data that syncrepl may have copied some (perhaps a very long) time ago when the data was replicated and de-referenced by syncrepl.
So probably as a consequence syncrepl client should ask for referrals to not be de-referenced, or the server should not de-reference referrals by default IFF the query is part of a syncrepl session. This assumes the server can easily distinguish a syncrepl client from a "end user". But it means the replica would de-reference referrals closest to the end user, which seems to best preserve the intent of a referral IMHO.
Cheers Brett
-
Brett ＠Google -
Howard Chu