Re: Problem binding two naming contexts

[Jan-Piet Mens <jpm@retail-sc.com>]

On Wed Nov 23 2005 at 14:25:54 CET, Pierangelo Masarati wrote:

> On Wed, 2005-11-23 at 13:52 +0100, Jan-Piet Mens wrote:
> > 
> > Thank you! That worked. I notice that binds on
> > uid=xx,ou=rsc,dc=virtual always work (i.e. they don't seem to be
> > checked on the target server); is that correct and/or can it
> > be changed?
> 
> No, it's not.  Please make sure you're not missing anything, post the
> logs (at "stats") of the remote and the proxy servers.  If the problem
> is confirmed, you should file an ITS.

I've upgraded to 2.3.12 and binds now work as I expected them to.


> > Furthermore, upon searching for sn=mens for example, only the 
> > results from the first URI are returned. Can that be changed
> > to include all results of all uri?
> 
> All should.  Again, please post logs for both the remote server and the
> proxy (now at "stats" + "stats2").


> Sorry, I got confused.  In fact, locally the databases see all the DN
> rewritten; so you should have everything rewritten; I don't think this
> can be done yet.  Stay with the other approach

Understood. Once again, thank you very much for your help, Pierangelo!


>                                                    please report about
> the issues we discussed above.  Try to deal with each of them
> separately, so please don't intermix the bind and the search logs.


The stats/stats2 log from the source server (the one we are discussing)
shows:

Nov 23 14:44:06 slapd[31242]: conn=1 op=1 SRCH base="dc=virtual" scope=2 deref=0 filter="(sn=mens)"
Nov 23 14:44:06 slapd[31242]: conn=1 op=1 SRCH attr=cn
Nov 23 14:44:06 slapd[31242]: conn=1 op=1 ENTRY dn="uid=jpm,ou=rsc,dc=virtual"
Nov 23 14:44:06 slapd[31242]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Nov 23 14:44:06 slapd[31242]: conn=1 op=2 UNBIND

I can't change the logging on target server at the moment, but here is the log entry
from that (its search base is correct, and it correctly finds one entry):

Nov 23 14:44:07 slapd[2282]: conn=2261387 op=2 SRCH attr=cn
Nov 23 14:44:07 slapd[2282]: conn=2261387 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=

The entry returned from dc=virtual (on the source) is the entry found on the
target. The missing entry is the one from the source BDB backend.

Just to be on the safe side: the entries ARE different (different classes, different
CN, etc.) but they share the same SN. That ought to be possible?

Regards,
	-JP